Build customer experiences on Protocol.
Use APIs, webhooks, events, objects, and custom applications to connect Protocol to the systems your service operation depends on.
const ticket = await protocol.tickets.create({
customer: "cus_123",
subject: "Billing issue",
priority: "high",
})
await protocol.workflows.run("billing-escalation", {
ticket: ticket.id,
})Conceptual example for product evaluation. Final SDK names and availability may change before developer access is enabled.
Connect the systems your service operation already trusts.
Use Protocol as the operating layer while systems of record, identity, data, commerce, and engineering remain connected.
Questions about extending Protocol.
APIs, webhooks, events, and custom applications should make integrations predictable rather than create another hidden layer of service logic.
What should a custom Protocol integration define first?+
Define the source of truth, data the service workflow actually needs, permissions, event behavior, and failure handling before writing the integration. This prevents a connection from quietly creating duplicate records or ambiguous ownership between systems.
How should webhook consumers handle delivery?+
Consumers should be idempotent and prepared for retries or duplicate delivery rather than assuming every event arrives once in perfect order. The production developer documentation should be treated as the source of truth for the event and signature contract that is actually supported.
Can existing systems remain authoritative after integration?+
Yes. A useful Protocol integration can expose service-relevant context or actions while the connected CRM, commerce, engineering, or data system remains authoritative for its own records. That keeps the integration focused and reduces unnecessary duplication.