What if a user genuinely belongs to more than one organization?

Then the resolution is ambiguous, and ambiguity is resolved by failing rather than guessing. Silently choosing one membership is how a request ends up writing to the wrong tenant.

How do public forms work if nothing from the client is trusted?

Through a signed token issued by the organization in advance. The token, not the form payload, carries the tenancy, so the form can be public without the organization being editable.

Does this apply to reads as well as writes?

Yes, though reads have a second line of defence in row-level policies. Writes are the more dangerous case because a mis-scoped write plants data in another tenant rather than merely exposing it.

Knowledge · Architecture

Server-Derived Organization Identity

A client can claim any organization it likes. Why the organization on a write must be resolved from a verified token or signed provider identity, never from the request.

Why should org_id never come from the client?

Anything a client sends can be edited by the client. If the organization on a write is taken from the request body, changing one field lets a request write into another tenant. The organization must be resolved on the server from a verified session or a signed provider identity, and any client-supplied value treated as an unverified claim.

Key takeaways

A request body is a claim, not evidence.
Tenant identity is resolved from the verified token, not the payload.
Machine callers need their own resolution path, not a shared fallback.
A claim that disagrees with the resolved authority is a rejection, not a merge.
Ambiguous membership must fail closed, never pick a row.

The three kinds of caller

A signed-in person: resolve the organization from the verified session's membership record.
A provider callback: resolve it from something the provider signed — the connected account, the destination phone number, the page identifier.
A scheduled job: resolve it from explicit job configuration, never from data the job happens to be processing.

What to do with a client-supplied organization value

Do not ignore it and do not trust it. Compare it against the resolved authority. If they match, the request is consistent and proceeds. If they differ, that is an attempted cross-tenant write: reject it and record it, because a mismatch is signal, not noise.

Identifiers are claims too

Tenant resolution alone is not enough. A caller — including a language model working from remembered context — can supply a record identifier that belongs to someone else, or that does not exist at all. Every identifier that arrives from outside must be checked for existence and for tenancy before it is used, not after the write.

Where URBLD fits

URBLD's tenant and actor invariant states that the organization is resolved server-side only: from organization membership for a signed-in user, from the connected account for payment events, from the destination number for inbound messaging, from the page record for lead webhooks, and from signed token tables for public capture. A body-supplied organization is accepted only when it matches, and a caller-supplied record identifier is verified against the resolved organization before use.

Security at URBLD Developers & API

FAQ

Frequently Asked Questions

Straight answers about how URBLD runs the business end-to-end.

Related knowledge

Human actors vs machine actors

Webhooks explained