If something does not work

Start with what you expected, what actually happened and the time of the request. If your other system shows a requestId or operationId, keep it for support.

The connection cannot find a property

Check that the key belongs to the right organisation, has View properties and rooms, and includes the property in its access. Check all result pages if there are more than 50 properties.

Find the property by its address and postcode before using the returned ID. Do not substitute a room ID or tenancy ID for a property ID.

Access is refused

Ask the provider to check the HTTP status:

• 401: the full API key may be missing, incorrect or revoked. The shortened identifier shown in the key list is not the full key.
• 403: a permission, property restriction or paid-plan eligibility check failed.
• 404: the record may not exist or may not be available to this key.

A key that can create tasks cannot necessarily read them. View and write permissions are separate.

A tenancy or task saved, but setup failed

Creation and follow-up setup are separate. Check whether the record exists and look up the returned operation using the same API key.

If it is still pending or processing, allow the background work to finish. If it reports failed, contact support with the operation ID. Do not create the tenancy or task again with a new retry key.

The tenant has not received an email

Creating a tenant or enabling portal access does not send an email. Your connection must explicitly request an invitation.

Check that access is enabled, the email is correct, and the tenant does not already have a linked account. HTTP 202 means queued. A completed invitation operation or tenant.invitation_sent event means the email provider accepted it, not that it reached the inbox or was opened.

If delivery is uncertain, check the operation and ask support before requesting another invitation.

An agreement exists, but the new tenant received no email

First check whether your connection explicitly requested their platform invitation with POST /api/v1/tenants/{id}/invite. Creating a tenant, enabling portal access and creating an agreement do not send that invitation. See Send an invitation explicitly.

If no invitation was requested, send one for the existing tenant when you are ready to invite them. If one was already requested, check its data.operationId with GET /api/v1/operations/{id} before requesting another. A completed invitation operation confirms email acceptance, not signup.

Agreement notification emails require a linked tenant account, enabled portal access and permitted email preferences. Before the tenant joins, the agreement can still be created successfully and will be waiting when they first sign in. A queued agreement notification is not an invitation and cannot onboard them.

Check the agreement's own operation separately using the top-level operationId returned by agreement creation. The agreement's sent_to_tenant status describes its availability; it is not proof that an email was sent. sentAt records email acceptance. The delivery operation may report a generic email failure when the tenant has not yet joined.

Do not create another tenant or agreement to resolve this. Notification retries are limited, so do not assume an old agreement email will send after signup. If its operation has failed, contact support with that operation ID. The existing agreement remains available through the tenant portal regardless of that email's delivery.

Template fields prevent agreement creation

For a saved template, check GET /api/v1/agreement-templates/{id} and match data.fields against the submitted fieldValues. For an inline document, check document.fields. Send exactly one of templateId or document, and put signatureRequired at the top level. For HTTP 422:

• missing_field_values: supply a non-blank value for every required Landlord / API field.
• invalid_field_values: a submitted key is not declared by this template. Use the exact key, without {{...}} braces; built-in placeholders do not belong in fieldValues.
• unfilled_template: correct unknown placeholders in the template or missing built-in tenancy details.
• validation_error: inspect the field details. Values must be strings, no longer than 500 characters, without line breaks.

Required Tenant fields can be left blank at creation. The tenant fills them in Letted before anyone signs. See the template guide for examples.

A reference is missing from the contract

externalId is a lookup reference, not document text. Declare a custom field such as tenancyReference, insert {{tenancyReference}} in the template, and pass fieldValues.tenancyReference when creating the agreement. Letted does not infer that value from a custom field's name.

A form asks for a signature

Switch Require signatures off before sending: either in the saved template, when creating the individual document, or on its unsent draft page. Changing the template does not change agreements already created. API creation inherits the template setting unless signatureRequired explicitly overrides it.

An unsigned form uses Complete form after required fields are saved. Completion freezes it without recording a signature. If your integration receives agreement.completed, read the agreement's signatureRequired and status; this event also covers completed unsigned forms.

Someone cannot complete or sign the agreement

Open the agreement in Letted and complete your required fields. Ask the other party to complete any required fields assigned to them. Tenants can edit Tenant fields; landlords manage Landlord / API fields. Save the details and review the updated contract before signing. If another person changed the document while it was open, reload and review the latest version.

Once anyone signs, or completes an unsigned form, all custom fields are frozen, including optional ones. Contact the landlord if a correction is needed; editing the saved template does not update an existing contract. The public API cannot update field values after creation.

The request timed out

Ask the connection provider to retry with the same API key, idempotency key, method, path and unchanged body. This protects against repeating a change that already saved.

If you receive 409, check for an existing external reference, an already linked tenant or an idempotency key reused for a different request. Find the original record before creating another.

Updates are not arriving

Check that the webhook is enabled, its API key is active and paid eligibility still applies. The key must have the matching view permissions and property access.

Send a test event and ask the receiving provider to check its logs and signature verification. If the destination was edited, it has a new signing secret; the old one will no longer verify new deliveries.

There is no webhook delivery-history panel in the current interface. Contact support for help investigating.

Too many requests

HTTP 429 means the connection has reached its per-key limit. It should wait for the Retry-After interval, currently 60 seconds, and then retry. Ask your provider to slow down repeated checks or use webhooks for changes where suitable.

A prompt for understanding an error

Read these Letted guides first:
https://app.letted.com/docs/troubleshooting
https://app.letted.com/docs/api-reference

If you cannot open them, ask me to paste the pages rather than guessing.

Using the Letted documentation linked above, explain this error in plain English:
[HTTP status, error code, message and request ID]

What should I check first? Could the record already have been saved?
Do not suggest repeating a write with a new idempotency key until we have
checked the original result. Ask me to remove API keys and personal data
before sharing logs. Give me a short message I can send to my provider.

When contacting support, include the intended action, approximate time, error code and request/operation ID. Do not send the full API key or webhook signing secret.