In August a base owner connected an app he'd built to your schedule, and it raised a fair question about protecting what runs on Embark. This is the answer. One documented way in, with keys you issue and revoke.
A base owner built an application against your schedule and showed it to the AI committee in August. He did it to demonstrate what was possible, and it worked.
It also raised a fair question. As more franchise developers build on Embark, you need a way to decide who reaches what, and a way to change your mind later.
That's what an API is for. You publish the data you're willing to share, you issue a key per base, and you take it back whenever you want. Ben has already built this pattern once, for Let's Book.
The high end is a ceiling, not a target. We bill for hours worked, invoiced the 1st for the prior month, net 14.
Engineering, architecture and QA. No design hours, because nothing here has a screen. Every row is v1 spine, so there's nothing to trim.
Schedule, availability, and the check-on and check-off records. Read-only in v1, so a franchise developer can build against your data with no way to write anything back into it.
Every developer gets a key scoped to one base. You issue it, you see what it pulls, and you revoke it without touching anything else on the platform.
Request limits per key, so one developer's script can't slow Embark down for the other bases. You set the quotas and we enforce them before the request reaches your database.
A published reference a franchise developer can build against without ever calling anyone at SailTime. For an API handed to outside builders, the documentation is half the product.
You add to Embark constantly. A version prefix on the API means each of those additions stops being a breaking change for the developers already building on top of you.
Error tracking and alerts on the public surface, so a broken integration reaches your inbox instead of reaching you as a phone call from a base owner on a Saturday.
It takes an afternoon. The developer gets a connection string and everything behind it, including the tables you never meant to share. Taking it back means changing credentials on your own systems.
“Just give him database access.”
It takes 4 weeks. The developer gets the fields you published, at a rate you set, under a key with his name on it. Taking it back is one click.
“Here's your key and the docs.”
“A broader discussion around how we protect any code, integrations, or other IP developed for SailTime.”
Documentation and key management run alongside the endpoint build instead of waiting for it to finish. That is how 4 weeks holds. The tradeoff is that a late change to the key model touches work already in flight, which is why week 1 settles it.
Say the word and we start with the working session between Ben and our architect. Everything here is v1 and read-only. The maintenance endpoints and the fuel ingestion wait until you've watched a franchise developer use this, and none of it waits on the mobile app decision.
Brian Hammond
VP of Sales, FYC Labs
bhammond@fyclabs.com
fyclabs.com