API conventions
Use the endpoint reference for exact request fields and response schemas. These conventions apply across the walkthroughs and guides.
If you are starting an integration, begin with Authentication, then choose Send a PDF or Create a contract from a template.
Base requirements
| Setting | Value |
|---|---|
| Resource base URL | https://{organization}.krebit.se/api/1.0 |
| Token endpoint | https://{organization}.krebit.se/api/oauth/token |
| Authentication | Authorization: Bearer <access_token> on resource requests |
| JSON responses | Accept: application/json |
| JSON request bodies | Content-Type: application/json |
| PDF uploads | Multipart form data with selected_file; let your HTTP client set the boundary |
Resources belong to the organization addressed by the URL. Use the domain and credentials configured in the authentication guide.
Responses and pagination
Read the schema for each endpoint rather than assuming every response has the same wrapper. For example, creating a signing returns its id at the top level, while paginated lists return items under data with links and meta.
List endpoints use page and limit. For example:
GET /api/1.0/signings?page=1&limit=20
Use the returned pagination metadata or links to continue. A list item can contain fewer fields than a detail response: contract lists omit input fields, so fetch a contract individually when you need its values.
Common status codes
| Code | What to do |
|---|---|
200 or 201 | Read the documented response body and save returned IDs when creating resources. |
204 | The operation succeeded without a response body. |
400 | Inspect the message for a request or workflow restriction, such as attempting to send an incomplete draft. |
401 | Check the access token or refresh it. |
403 | Check user access and whether the resource can be changed in its current state. |
404 | Check the ID and organization. Signed downloads also return this while the signed file is unavailable. |
422 | Correct the validation errors before retrying. |
429 | Delay requests and respect retry guidance in the response. |
5xx | Treat the result as potentially uncertain and reconcile state before repeating a write. |
Individual endpoint pages document their specific responses.
Error format
Validation responses can identify the fields that need attention:
{
"message": "The given data was invalid.",
"errors": {
"fields.0.value": ["The selected value is invalid."]
}
}
Workflow errors may provide a message without an errors object. Handle both shapes, and do not depend on the exact wording of a message.
Rate limiting & idempotency
If a request times out, it may already have succeeded. Save returned resource IDs and check the current state before repeating a write. Repeating a creation request can create another signing, document, contract, or webhook registration.
Retry reads and transient failures with a bounded backoff policy. Correct validation and permission errors first. For sending, inspect the signing's state before issuing another send request.
Webhook retries are separate from API request retries. Deduplicate webhook deliveries using the event id; see Webhooks and results.
Find an endpoint
Use API reference in the sidebar for OAuth, Signings, Contracts, Users, Webhook registrations, and Webhook events. The guides explain the workflow; these pages provide its request and response definitions.