AI integration prompts

These optional prompts follow the same workflow as the guides. Give your coding assistant the relevant pages and the OpenAPI specification, then add your language, framework, HTTP client, storage, and testing conventions.

Start with Authentication, choose Send a PDF or Create a contract from a template, and use Webhooks and results for completion handling. The API reference defines request and response shapes.

Build the workflow

Choose either PDF upload or contract templates in the prompt before using it:

Build a Krebit Sign integration for my project using the supplied guides and OpenAPI specification.

Project context:
- Language and framework:
- HTTP client:
- Credential and data storage:
- Testing tools:
- Document workflow: PDF upload OR contract template

Implement this sequence:
1. Authorize a user with OAuth Authorization Code, validate state, and store access and refresh tokens securely. Keep credentials on the backend.
2. Create a signing draft and persist its ID.
3. For PDF upload: upload selected_file and store the document ID.
   For templates: fetch the template's fields, create a contract with template_id and optional field values, and store its ID.
4. Add recipients using fields supported by the schema. Use the separate order endpoint if reordering is needed; positions are zero-based within each recipient type group.
5. Send the signing and track its state.
6. Handle verified completion webhooks, download signed documents, and retrieve contract fields when contract_id is present.

Use the organization's base URL and bearer token consistently. Do not invent endpoints or response fields. Explain any missing requirement before generating code.

Add contract field handling

Use this follow-up for a template-based workflow:

Implement contract prefilling and signed-value retrieval using the contract guide and reference.

- Prefer optional named keys when available. Each input uses exactly one key or id, plus value.
- Use template field UUIDs at creation and contract field UUIDs for subsequent updates.
- Omitted fields keep their values or template defaults; null clears a value.
- Respect email and choice validation, locked recipient fields, and all-or-nothing validation failures.
- API updates apply only while the signing and contract are editable drafts. Recipients complete the contract through the signing flow.
- Contract completed_at means the PDF was finalized; signed_at means all signatures are complete.
- Follow data.document.signing_id and data.document.contract_id from completion events to retrieve fields. Skip the contract lookup when contract_id is null.

Review before shipping

Review the integration against the published schemas and add tests for:

- OAuth callback state validation, token refresh, expired tokens, and denied access.
- PDF or contract creation, recipient configuration, sending, and validation failures.
- Uncertain POST outcomes: creating a signing, document, contract, or webhook twice can create duplicates. Reconcile stored IDs and current API state before retrying.
- Webhook HMAC verification over the raw body, including missing or malformed signatures.
- Duplicate and out-of-order webhook deliveries. Deduplicate by payload id and use payload event as the event name.
- Completion of one document versus the whole signing, unavailable signed files, and null contract links.
- Page-based pagination using page and limit.

Keep credentials and personal field values out of logs. Return code that fits the project's existing conventions, plus the tests and any unresolved assumptions.

Check the generated code against the guides before sending real invitations. Start with an address you control, then verify that the signed PDF and any contract values arrive in your application.