> ## Documentation Index > Fetch the complete documentation index at: https://www.composer.id/llms.txt > Use this file to discover all available pages before exploring further. # Juro > Juro (Signature & Contract Management): the API posture, publish target and field mapping composerID publishes a decision reference through. This page records how composerID publishes into Juro: the vendor's API posture, the publish target and field mapping, and the documentation each claim rests on. It is for anyone evaluating the connection or building against it. Juro is a browser-native contract automation and e-signature platform where templates, smartfields, approval flows and signing live in one workspace. composerID publishes into Juro by creating a contract from a named template and populating its smartfields, so the paperwork for a decision already taken is drafted and routed for signature without anyone re-keying it. Juro is the execution and evidence layer for that decision, not the system that makes it. Category: Signature & Contract Management. Coverage status: Specification mapped. Vendor documentation: public developer portal. ## Integration path How composerID connects to this destination, at a glance. | Step | Detail | | -------------------- | -------------------------------------------------------------------------------------------------------------------------------------------------------------- | | Authentication | API key sent as an x-api-key request header. | | composerID publishes | Contract (create from template): Contract name (commonly driven by the counterparty legal name smartfield, which names both the contract and the signing side) | | Intent ID lands on | `contract` `fields[].reference_uid`, written into the destination record | | Back-sync | Webhooks: the destination pushes events; composerID verifies each delivery and lands it on the intent's timeline. | ## Vendor documentation ## API posture | Aspect | Detail | | -------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ | | Authentication | API key sent as an x-api-key request header. The key is issued per account from Settings → Integrations → API & webhooks. | | Style | REST/JSON with a published OpenAPI specification. Collection pagination uses skip and limit query parameters (limit defaults to 50, maximum 200). | | Base URL | [https://api.juro.com/v3](https://api.juro.com/v3) (a sandbox at api-sandbox.juro.io is available on request, not self-serve) | | Webhooks | Native push webhooks. Subscriptions are registered in-app under Settings → Integrations → API & webhooks and deliver asynchronous notifications across the contract lifecycle - creation, views, approvals and signature - with the fully-signed PDF passable downstream. Confirm the current event list and payload-signing scheme against the API docs when wiring a tenant. | | Events posture | Webhooks | | Rate limits | Documented as a tiered monthly request quota plus a per-second throttle with a short burst allowance; the quota depends on the account's API tier, so confirm the tenant's limits against the published tiers before planning batch volume. | | Objects | Contracts (/v3/contracts, plus /v3/contracts/upload to create from an existing PDF), templates (referenced by templateId on create), smartfields (fields\[] addressed by uid), Q\&A answers (answers\[]), signatories and counterparties, webhook subscriptions. | ## Publish target and field mapping Each object below pairs the canonical intent fields with the destination's own fields and operations. The mapping is indicative until it is confirmed against a tenant at onboarding. | Mapping | Detail | | ------------------------ | ----------------------------------------------------------------------------------------------------------------------------- | | Canonical to destination | title | | Target | Contract name (commonly driven by the counterparty legal name smartfield, which names both the contract and the signing side) | | Requirement | Required | | Notes | The template determines which smartfields exist; the create call fills them by uid, not by display label. | | Mapping | Detail | | ------------------------ | -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | Canonical to destination | intent\_id | | Target | fields\[].uid = the reference field's uid, fields\[].value = the Intent ID | | Requirement | Tenant required | | Notes | Juro's public docs describe no first-class external-ID or metadata property on the contract object, so the Intent ID rides a purpose-built smartfield agreed per tenant. It reads back on GET and on webhook payloads, which is what makes re-publishing idempotent. | | Mapping | Detail | | ------------------------ | ----------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | Canonical to destination | counterparty | | Target | Counterparty legal name smartfield plus signatory smartfields / Q\&A answers | | Requirement | Required | | Notes | Smartfields are filled either by the owner at create time or by the counterparty answering a Q\&A flow before signing - decide per template which side owns each field. | | Mapping | Detail | | ------------------------ | -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | Canonical to destination | start\_date, end\_date, value | | Target | Date and text smartfields addressed by uid | | Requirement | Tenant | | Notes | Choice-type smartfields reject values outside the template's allowed list, so any composerID enumeration must be reconciled against the template's choices before first publish. | | Mapping | Detail | | ------------------------ | --------------------------------------------------------------------------------------------------------------------- | | Canonical to destination | defence\_file\_ref | | Target | Consumer endpoint, correlated on the reference smartfield returned in the payload | | Requirement | Recommended | | Notes | Signature and lifecycle events close the loop; the signed PDF is what the audit spine's evidence reference points at. | Everything material is template-scoped and therefore per-customer: which templates exist, which smartfields they carry, each smartfield's uid and type (text, date or choice) and, for choice fields, the permitted values. Whether a smartfield is filled by the publisher at create time or by the counterparty in the pre-signing Q\&A is also a template decision. Because no generic external-ID slot is documented, each tenant must agree a dedicated reference smartfield for the Intent ID before go-live. Webhook endpoints, the signing secret and the API tier are configured in the customer's own Juro account. ## Next steps The five ways composerID reaches a destination, and the minimum a destination must offer. Plan, preflight and publish: how a decision becomes a valid record in a destination. Every destination composerID documents, with its category and coverage status.