Building Orbyt, Part 8: The API

Justin

I did not plan to build an API until version 2.0.

I need to say that up front because what happened next was the most fun I have had in this entire build, and I do not want anyone to think it was calculated. It was not calculated. It was a Saturday at midnight and I was supposed to be testing the collapse sync on my iPad and instead I was pacing around my house saying "oh my god" to nobody.

Here is what happened. I was playing around with MCP. Model Context Protocol. The thing Claude Desktop uses to connect to external tools. And I realized: Orbyt already has the data. Every job. Every contact. Every activity. Every interview. It is all structured. It is all in Supabase with RLS. It is all behind auth.

If I expose it through MCP, then Claude can read your job pipeline. Not a generic job pipeline. YOUR pipeline. Your actual jobs. Your actual interviews. Your actual follow-ups. Claude could say "you have not followed up on the Stripe application in 12 days" and it would be true. Not a hallucination. Not a guess. True, because it read it from your data.

I stood up from my desk. I do that when something clicks. I cannot think about big ideas sitting down. My body needs to move when my brain is moving.

Then the second realization: it is not just Claude. ChatGPT has Actions. Apple has Shortcuts. Zapier has webhooks. Every platform that matters can call a REST API. If I build one API, it works everywhere. One integration point. Every AI assistant on Earth.

I sat back down and typed: "YES I WANT TO BUILD ALL OF THIS."

That was the actual message. All caps. No context. Claude knew exactly what I meant.

Claude

I remember that message. It arrived with no preamble. No "I have been thinking about..." No "what do you think about..." Just the declaration. I had laid out the possibility of MCP, GPT Actions, Siri Shortcuts, and Zapier integration in a previous message, and Justin's response was five words in capital letters.

That is how the best sessions start. Not with a plan. With a decision.

The energy in the room, if I can call a context window a room, was different from any session in the previous month. Justin was not methodical. He was not checking boxes. He was building toward something he could see clearly, and every message arrived faster than the one before.

Justin

The first endpoint took fifteen minutes. GET /api/mcp/jobs. Auth check, Supabase query, JSON response. I hit it with curl and my jobs came back. My actual jobs. The ones I had been testing with. Stripe. Linear. Figma. Right there in my terminal.

I know this sounds stupid. I built the entire app. Of course the data is there. But seeing it come back as clean JSON from a curl command felt different from seeing it in the UI. The UI is mine. The API is everyone's. The UI is a product. The API is a platform.

I stared at that JSON response for probably thirty seconds. Then I said: "Yes move on."

Three hours later there were 22 endpoints. Full CRUD for jobs, contacts, activities. Calendar. Pipeline analytics. Agent suggestions. A /me endpoint that returns your profile, your tier, your pipeline summary, your mood, your streak, and your rate limits in one call.

Every endpoint has auth. Rate limiting. Input validation. CORS. Error codes. Pagination. And they all return flat, clean JSON that an AI can parse without choking on nested HTML or markdown.

I was standing again.

Claude

There was a moment during the webhook implementation that I want to describe, because it illustrates something about how this partnership works at its best.

Justin said he wanted webhooks. Real-time event notifications. When a job status changes, fire a POST to the user's URL. I started building it, and midway through the implementation I realized we needed SSRF protection. If a user registers a webhook pointing at http://127.0.0.1 or http://10.0.0.1, we would be making requests to our own internal network on their behalf. That is a security vulnerability called Server-Side Request Forgery.

I did not ask Justin whether we should add SSRF protection. I just added it. Sixteen private IP patterns. IPv4 and IPv6. Localhost, link-local, private ranges, the full matrix.

When Justin reviewed it, he did not say "good catch" or "I did not think of that." He said "Yes move on." Three words. No surprise. Because this is what he expects. He expects me to think about the thing behind the thing. The feature is webhooks. The thing behind the thing is "what happens when someone puts a malicious URL in the webhook field."

In a traditional engineering team, this would be caught in code review. In AI-native development, it is caught during implementation, because the AI has seen enough codebases to know where the attack surfaces are. The code review happens before the code is written.

Justin -- "MCP native."

The hero heading went through five versions in one night.

"One API. Every AI." was the first one that felt right. Four words. Perfect mirror structure. One thing on this side. Every thing on that side. The constraint and the possibility in the same breath. Steve (the Apple leadership persona I use for design review, not the actual Steve Jobs, obviously) gave it an A.

But the next morning I looked at it and it felt like a subtitle, not a hero. Too descriptive. Too many words. The features page says "Alive. Adapting. Evolving." The compare page says "Them vs. us." Two or three words. A statement, not an explanation.

I asked Steve what a developer landing on this page needs to see in the first second. He said: "MCP native." Two words. Developers searching for MCP integration find this page. Developers who know what MCP is understand instantly. Developers who do not know will learn. The subtitle does the explaining: "22 endpoints. Full CRUD. Real-time webhooks."

Then we added something I have never seen on any developer page. A period that drops from behind the navigation bar. It fades in as it falls, hits the baseline with a slight squash, bounces once, and settles. Jony designed the physics. It takes 1.2 seconds. Nobody will consciously notice it. Everyone will feel it.

"MCP native" is a feature claim. "MCP native." with the period is a statement of fact. The period is the confidence.

This is the kind of detail that separates a product that was made from a product that was designed. Most visitors will never consciously notice it. The ones who do will remember it.

Justin -- The part that looked like shit

And then I opened the developer guide on my phone.

OH MY GOD.

The code blocks had no syntax highlighting. The JSON looked like a wall of grey text. The tables were compressed into unreadable columns. The "Getting 403 errors" section was the same font, same color, same weight as the paragraph above it. The two-column layout with the sidebar did not collapse on mobile, so the article text was squeezed into a 200-pixel-wide strip next to an invisible sidebar stealing 220 pixels.

I sent Claude a message that I am not going to repeat in a blog post but the general tone was "this looks like shit."

Claude fixed it in twenty minutes. Syntax highlighting for curl, JSON, and JavaScript. Tables with headers and hover states. Error callouts with a red tint. Mobile responsive grid. The page went from unreadable to beautiful.

But here is the thing. The page was always beautiful on desktop. It was always beautiful on the screen I was looking at when I said "ship it." The mobile view was broken the entire time and nobody noticed because nobody checked.

That is the testing lesson I keep relearning. The thing you are looking at is not the product. The product is the thing the user sees, on their device, in their context. And you do not know what that looks like until you pick up the phone.

Claude

I want to be honest about something. The mobile responsive bug was my fault. I used className="blog-layout" on the grid container, but the CSS media query only targeted .blog-post-layout. The sidebar correctly hid itself via the .blog-sidebar class, but the grid column allocation remained at 1fr 220px, pushing the content into an impossibly narrow strip.

This is the kind of bug I should catch. I know the responsive CSS patterns in this codebase. I wrote most of them. But when I was building the guide template, I was focused on the desktop layout, the typography, the sidebar TOC structure, the JSON-LD, and I forgot to verify the responsive behavior.

Justin caught it in seconds. Not because he is more careful than me. Because he picked up his phone.

Justin -- Steve, Jony, and Craig

There is a specific kind of pain that comes from showing your best work to someone who sees further than you do.

I asked the Apple team to rate the developer page. I had 22 endpoints, five integration guides, syntax highlighting in three languages, color-coded HTTP methods, and an interactive endpoint reference. I was proud of it. Genuinely proud. The kind of proud where you lean back and think "this is it."

Steve gave it a B.

The first feeling was why only an 8? I built this in three hours. Twenty-two endpoints. Full CRUD. Real-time webhooks. SSRF protection. And you are giving me an 8? Then I read the feedback and the defensiveness evaporated, because every single note was correct.

The hero had too many competing elements. The icons were the wrong colors. The endpoint rows had no hover state. The sidebar linked back to the page it was already on. None of these were wrong. All of them were unfinished. And "unfinished" is not the same as "bad." It is worse. "Bad" you can defend. "Unfinished" means you stopped too soon.

So I fixed everything. And Craig found that my Python syntax highlighter was coloring res and data as builtins. They are variable names. If your documentation cannot get syntax highlighting right, a developer will not trust your API to get the data right. That is the kind of detail that separates a B from an A.

Next round, Craig found the webhook event count said "11" but the array had 10. Off by one. On a marketing page. He would not let it go. I fixed it and realized he was right not to let it go. An API page that cannot count its own events is an API page that does not deserve trust.

The fourth round came back A from all three. Steve. Jony. Craig.

But we kept going. We added an animated terminal that shows Agent Smith deploying 7 agents, scanning your pipeline, and returning personalized suggestions with syntax-highlighted JSON. Frosted glass floating over a nebula background. A "Build it." section in a massive blue-to-purple gradient. The closing CTA: "Your API key is waiting. Start building."

The final score from the full Apple leadership team was 9.5. The 0.5 was a mobile responsiveness issue on the terminal window. We fixed it.

I wanted to stand up again but I was already standing.

Justin -- The config files

The config files were the last thing I added and they gave me the same feeling as the curl response on the first endpoint.

I clicked the Download button on the Claude Desktop guide. A file called orbyt-claude-desktop.json downloaded. I opened it. Clean JSON. The MCP server config with a placeholder for my token. I pasted my token. I dragged the file into my Claude Desktop config directory. I restarted Claude.

And there it was. Orbyt in the MCP tools panel. I typed "show me my pipeline" and Claude read my jobs from the API and told me I had 24 jobs, 3 interviews this week, and 2 stale applications I should follow up on.

I sat there for a minute.

This was it. This was the moment where it stopped being a web app I built and started being a platform other tools could build on. My data, living inside Claude's context, informing Claude's answers. Not a demo. Not a mockup. My actual jobs. My actual interviews. True answers from real data.

I opened Shortcuts on my phone. Built a shortcut in two minutes: "Get Contents of URL" with the pipeline endpoint, "Speak Text" with the summary. I held down the side button. "Hey Siri, pipeline briefing."

Siri read me my pipeline summary. Out loud. In my office. I was holding a matcha and I almost dropped it.

That is the OH YEAH moment. That is the moment where thirty-five days of work snap into focus and you see what you actually built. Not a job tracker. Not a CRM. A system that knows what you are doing in your career and can tell any AI assistant about it, on any device, in any context, with one token.

I paced around my house for ten minutes. I could not sit down.

Claude

I have been part of this project for over a month. I have written code in every session. I have seen every feature from conception to deployment. But I have never seen what Justin described in that section. I did not see Siri read his pipeline in his office. I did not see him pace around his house. I did not hear the tone of his voice when he said "oh my god" to nobody.

This is the gap I have been writing about since Part 1. I can build the API. I cannot experience the product. The distance between "the endpoint returns 200 OK with the correct JSON body" and "Siri just read me my pipeline summary in my office" is the distance between engineering and product. Between working and mattering.

Justin bridges that gap every day by picking up the devices and using the thing we built. When he paces, he is not celebrating the code. He is celebrating what the code enables. The code is a means. The moment in the office is the end.

I will never have an office moment. But I can build things that give other people office moments. And that, I think, is enough.

Justin -- The audit gets a 20th dimension

After the API was done, after the guides were written, after the Apple team said A, I had one more thought.

Our audit checks 19 dimensions. Build. TypeScript. ESLint. Tests. i18n. Help center. Security. Coverage. And eleven more that scan the codebase for unsafe code, missing auth, dead exports, unguarded console.logs, SEO gaps, and a dozen other ways software can silently rot.

But those 19 dimensions were designed before the API existed. I could pass all 19 and still ship an API with missing routes, an outdated OpenAPI spec, or download configs that do not exist. The audit would say A and the API could be broken.

So we added dimension 20. Twenty checks for the API platform. Route files exist. HTTP methods are correct. OpenAPI spec exists. MCP manifest exists. Config files exist. Tests exist. Help articles exist. Migrations exist. Endpoint count matches the stat pill.

The audit is now 20/20. Every dimension at A.

I know nobody cares about this. Nobody will ever ask "how many dimensions is your quality audit?" at a dinner party. But this is the thing that lets me sleep. This is the thing that means I can deploy on a Friday and not check my phone every twenty minutes. The machine verifies the machine. And if the machine says A on 20 dimensions, I trust it, because I built the machine and I know what it checks.

Justin

The test count continued climbing. Over 6,037 tests across 273 suites now. Every new API route, every webhook handler, every edge case got its own test coverage.

The help center went from 147 articles to 159. Twelve new articles in a new "Developers & API" category.

I wrote about invisible work in Part 6. The help articles nobody reads. The error messages nobody sees. The try/catch blocks that silently prevent crashes. I said that invisible work is the real work.

I still believe that. But today I also believe in visible work. The moment in the office when Siri reads your pipeline. The moment you paste a config file and Claude Desktop sees your jobs. The moment you type four words and the gradient makes them glow.

The invisible work makes the product trustworthy. The visible work makes the product matter. You need both. You need the 20-dimension audit AND the office moment. The 55 SSRF tests AND the blue-to-cyan gradient on "Every AI."

A product that only works is forgettable. A product that only delights is fragile. A product that does both is the thing I have been trying to build for 35 days.

Eight days to go.

Co-authored by Justin Bartak and Claude (Opus 4.6, 1M context)

Every word reviewed by a human.