The objects
Every resource carries an
object field naming its type, so a handler can
switch on it wherever the resource arrives - nested under expand[], inside an
event, or in a webhook.
Modes and the sandbox
Every key is eitherclmt_live_ or clmt_test_, and everything a key
touches inherits its mode. Test and live are separate worlds: a test key
never lists, reads, or changes a live object (an id from one never resolves in
the other), the same Idempotency-Key is a different key in each mode, a test
company is never fulfilled, and a test charge never rides a statement. Webhook
endpoints are registered per mode, so test events only reach test endpoints.
In test mode the whole surface works - companies, orders, requirements, files,
and tax filings all exist and every event fires - but nothing advances on its
own, because Clemta is not fulfilling it. You advance it:
POST /sandbox/companies/{id}/simulate takes an event and the fields it
needs, and applies the change exactly as a live change would, the once-only
rules included, then delivers the resulting events to your test webhooks.
The one design rule
Your customer is yours. Clemta never emails, texts, or otherwise contacts the people behind a partner-created company. Their identity lives on your account object, and they never become a Clemta user. The pages Clemta hosts for them (identity verification, document signing) carry your brand. Everything that would normally reach the customer reaches you instead, as an event - so you can pass it on in your own voice. See Whitelabel.Where to go next
- Company lifecycle - statuses, stages, and what fires when.
- Requirements - documents, forms and asks, and how your client can answer without an API key.
- Service orders - ordering, fulfillment steps, and the form standard.
- Files - reading deliverables back.