Skip to main content
The Modular API provides an integration that enables full programmatic control over tenant workflows, including document processing, identity verification, banking connectivity, and forensic analysis. This page focuses exclusively on API-based integration. Use the Modular API Reference section for the complete list of endpoints, request formats, and response schemas.

Quickstart

Generate an access token with your API key credentials and make your first request.

Modular API Reference

Explore Modular API endpoints, request parameters, responses, and authentication requirements.

Authentication

All Modular API interactions are scoped to API key credentials: a client_id and client_secret. An API key represents your integration and acts as the root container for tenants, webhooks, and processing workflows. To authenticate requests, exchange your API key credentials with Generate Access Token using HTTP Basic Authentication (see the Authentication guide). Then include the one-hour token in the request headers when calling protected endpoints.
Each API key can manage multiple tenants. Webhooks are configured at the API key level and apply to all tenants created under that key.

Base URLs

Choose the base URL for your environment:
https://api.skortorent.com/api/v1
Production is the default Modular API reference environment. Switch to Sandbox when testing with sandbox credentials.

Webhooks

Webhooks allow SKOR to notify your system about important events asynchronously. Webhooks are configured per API key and deliver event notifications for all tenants associated with that key. These events help your system react when specific processes are completed. When you create a webhook, you can provide an optional signing secret for that URL. SKOR keeps this value server-side and uses the Svix signing scheme to sign the exact JSON request body. The secret itself is never sent in a webhook request.
Create webhook request
You can replace the secret through Update Webhook. Send null or an empty string to remove it. List Webhooks and Get Webhook return the configured secret, so treat those API responses as sensitive. For a webhook with a configured secret, each request includes these headers:
Install the official Svix library:
Verify the unmodified raw request body with the configured secret:
Verify a webhook signature with Svix
The verification method checks the signature and rejects timestamps outside Svix’s allowed tolerance. It throws when verification fails. For an Express endpoint, use a raw body parser before any global JSON parser:
Express verification endpoint
The SKOR backend also exposes POST /webhook-test for delivery testing. Set SKOR_WEBHOOK_TEST_SECRET to the same secret configured for that test webhook before using the endpoint.
Verify the signature against the raw body before parsing or modifying the JSON. A webhook URL, including a Convex HTTP action URL, is only the delivery destination. Configure a separate random secret when creating the webhook.
  • Tenant lifecycle events — TENANT_CREATED, TENANT_UPDATED, TENANT_DELETED, TENANT_ONBOARDING_COMPLETED
  • Application updates — APPLICATION_UPDATED
  • Document analysis completion — DOCUMENT_ANALYSIS_DATA
  • Cl@ve processing success — CLAVE_SUCCESS
  • KYC verification result — KYC_VERIFICATION_DATA
  • Forensic analysis completion — FORENSIC_ANALYSIS_DATA
  • Financial analysis result — FINANCIAL_ANALYSIS_SUCCESS, FINANCIAL_ANALYSIS_FAILURE

Retries and redelivery

Your endpoint must answer with a 2xx status within 10 seconds. Any other answer, a timeout or a connection error counts as a failed delivery. SKOR retries a failed delivery up to 2 more times, with the same body and svix-id: Retries are checked every 5 minutes, so each can arrive up to 5 minutes later than shown. Because svix-id stays the same, store it and skip any event you have already processed. To recover events that were not delivered:
  • List Undelivered Events returns events that are still retrying (pending) or whose retries all failed (failed). An event leaves this list as soon as it is delivered.
  • Redeliver Event sends one of those events again right away.
Each webhook delivery is a POST with a JSON body of the form { "event": <EVENT_NAME>, "data": <payload> }. TENANT_ONBOARDING_COMPLETED is emitted after a tenant completes onboarding in the modular iframe. Its data includes the completed tenant id. The iframe also sends a browser message with the same event name so the JavaScript SDK can close the embedded session immediately; the signed webhook is the server-to-server notification. Register an endpoint with Create Webhook.

Tenant management

Tenants are entities that you manage through the Modular API. Each tenant is associated with a specific API key. When you create a tenant with basic information, SKOR automatically advances the tenant to step 2 (KYC verification). If onboarding is left unfinished, it resumes from where it stopped. Once a tenant is created, you can manage subsequent actions such as document uploads, identity verification, banking connections, and forensic analysis. Create a tenant with Create Tenant. You can also Get Tenant, Get All Tenants, Update Tenant, and Delete Tenant.

Guarantors

A guarantor always backs a tenant inside an application. Use Link Guarantor with the application_id: the guarantor joins that application with is_guarantor: true and guarantor_of set to the tenant, and the two tenant accounts are linked. The link is active right away and no invite is sent.
  • The tenant must be a flatmate in that application, not a guarantor.
  • A guarantor cannot have guarantors: someone with guarantors in the application cannot become a guarantor in it.
Remove a guarantor with Unlink Guarantor. Pass application_id to remove them from one application only; the accounts stay linked while another application still has them as the tenant’s guarantor. Without it they leave every application where they back the tenant, and the accounts are unlinked. Both accounts stay. Get Application shows is_guarantor and guarantor_of for each participant.

Applications

Applications group tenants who apply together. Each application has a lead. The lead manages the group. Create an application with Create Application. Then manage it with these endpoints:
  • Get Application — see the application, its participants, and its feedback (feedback is null when none has been saved).
  • Update Application — rename the application.
  • Add Participants — add people. New people get an invite email.
  • Update Participant — change a participant’s name or guarantor flag. The email cannot be changed.
  • Remove Participant — remove a participant. The lead cannot be removed.
  • Delete Application — delete the application. It is unlinked from all properties and no longer appears in any endpoint. An application that has been awarded a property cannot be deleted (409).
Any change to an application sends an APPLICATION_UPDATED webhook. Deleting an application sends no webhook.

Application feedback

Use feedback to request missing items or leave a note on an application. Feedback belongs to one application and is scoped to your API key.
  • Save feedback with Save Application Feedback (PUT /applications/{applicationId}/feedback). Provide documents (up to 50 strings, max 255 characters each) and/or message (max 2000 characters). Omitted fields keep their existing values. Send explicit documents: [] or message: "" to clear that field. An empty request is rejected with 400.
  • Saving feedback sets status to OPEN and resolved_at to null.
  • Mark feedback done with Resolve Application Feedback (PATCH /applications/{applicationId}/feedback/resolve). It takes no request body, preserves documents and message, and sets status to RESOLVED with resolved_at and updated_at timestamps.
  • Resolving already resolved feedback succeeds without changing timestamps or sending another webhook.
  • 404 means the application is inaccessible or no feedback exists. 409 means the feedback changed during resolve — retry the resolve.
  • Feedback saved before statuses were introduced reads as OPEN with resolved_at: null.
  • Saving or first resolving feedback sends an APPLICATION_UPDATED webhook. Fetch the application to read the updated feedback object.

Landlord report session

Display the landlord report for a specific property and application using the browser SDK. The report requires two identifiers you already create in your integration: a propertyId from the Property Management API and an applicationId from the Modular API. Generate a short-lived landlord token on your server, then pass all three values to the SDK to render the report.
1

Prepare the identifiers

Keep the property_id returned when you create a property and the application_id returned when you create an application (POST /applications/create-application). You will need both as propertyId and applicationId to show the report. No additional tenant setup is required.
2

Generate a landlord token

Call Generate Landlord Token (GET /landlords/token) from your server with your API access token. No request body is required.
The response returns a short-lived token for the browser.
3

Show the report in the browser

Add a container to your page:
Then start the SDK session with the token and both IDs. Both propertyId and applicationId are required — the report will not render if either is missing.
The SDK embeds the report automatically. Standard callbacks such as onLoad, onError, and onCancel, and the height option work the same as for tenant sessions.
Pass propertyId and applicationId exactly as received from the API. If the report does not load, verify both IDs belong to the same landlord and are not empty.

Document upload and download

Documents can be uploaded for a tenant at any point after creation. Examples include payslips, bank statements, tax returns, and identity documents. Uploaded documents are stored in the SKOR database and can be retrieved later when required.
  • Upload documents for a tenant using the Documents API.
  • Trigger document analysis automatically after successful upload.
  • Receive webhook events when document analysis is completed.
  • Download documents retrieved from Cl@ve.
See Upload Tenant Documents, Get Tenant Documents, and Initiate Cl@ve.

Identity verification

KYC verifies the tenant’s identity using official identity documents. Build your own document capture and run verification in two steps. Start by fetching the supported catalogue with Get Supported KYC Documents (GET /tenants/kyc/supported-documents) to populate your document-type and country selectors. Each entry is a valid document_type + issuing_country combination.
1

Start verification

Call Initiate KYC Verification (POST /tenants/{tenantId}/kyc) as multipart/form-data with doc_type (passport, driving_licence, national_identity_card, or residence_permit), issuing_country (3-letter code, e.g. ESP), and files: front (required, max 10 MB; PDF, JPEG, JPG, or PNG) and back (required for all types except passport). SKOR uploads the document(s) and starts verification, returning identifiers (workflow_run_id, etc.) you can use to track status. If a verification is already pending, the call is rejected with KYC already in progress for this tenant.
2

Check the result

Call Get KYC Verification Status (GET /tenants/{tenantId}/kyc/status/{workflowRunId}) with the workflow_run_id (UUID) to see the current status. Poll this endpoint or listen for the KYC_VERIFICATION_DATA webhook.

Financial scoring

Banking data is analyzed and used in financial assessments. You can get a tenant’s banking data in two ways:
  • Connect a bank: send the tenant through the bank connection flow with Initiate Bank.
  • Upload a bank statement: send a PDF statement (max 8 MB, at least 3 months, showing the account holder name) with Upload Bank Statement. It goes through the same processing as a statement uploaded in the SKOR platform.
Both ways end with the FINANCIAL_ANALYSIS_SUCCESS or FINANCIAL_ANALYSIS_FAILURE webhook.
Bank statement processing runs in the background and can take a while. The upload responds right away with status PROCESSING. Call it once per statement and wait for the webhook.

Forensic analysis

Forensic analysis evaluates all available tenant data to detect inconsistencies, fraud indicators, and financial risk signals.
You do not need to manually trigger forensic analysis in most cases.
Forensic analysis can run automatically when documents are uploaded, after KYC completion, and after successful bank connectivity. You may still trigger it manually if required. See Run Forensic Analysis. Retrieve results with Tenant Skor Analysis Details or the full Get Tenant response.

End-to-end flow

1

Generate an access token

Generate an access token with Generate Access Token using your API key credentials via HTTP Basic Authentication. Use this token to authenticate all subsequent API requests.
2

Configure webhooks

Configure webhooks to receive asynchronous notifications for document analysis, Cl@ve events, KYC completion, forensic analysis, and financial analysis. Webhooks are optional, but strongly recommended for long-running processes.
3

Create tenants under the API key

Create a tenant by providing their basic personal details. When you create a tenant with basic information, SKOR automatically advances the tenant to step 2 (KYC verification). If onboarding is left unfinished, it resumes from where it stopped. The endpoint documentation lists all required fields. Identification number and postcode are used to run Experian checks for defaulter and risk status.
4

Upload documents or retrieve them from Cl@ve

Upload tenant documents manually, retrieve them through Cl@ve, or use both methods. Document submission is mandatory and acts as a blocking dependency for forensic analysis.
5

Initiate KYC verification

Complete identity verification for the tenant. KYC verification is mandatory, and forensic analysis will not be triggered unless KYC has completed successfully.
6

Connect the tenant's bank

Connect the tenant’s bank account, or upload their bank statement with Upload Bank Statement. This step is optional, but recommended because banking data is required for Financial SKOR generation.
7

Consume results through APIs and webhooks

Retrieve tenant operational data through APIs and consume asynchronous events delivered through webhooks.