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: aclient_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.
Base URLs
Choose the base URL for your environment:- Production
- Sandbox
https://api.skortorent.com/api/v1Webhooks
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 signingsecret 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
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:
Verify a webhook signature with Svix
Express verification endpoint
POST /webhook-test for delivery testing. Set SKOR_WEBHOOK_TEST_SECRET to the same secret configured for that test webhook before using the endpoint.
- 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 andsvix-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.
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 theapplication_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.
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 (
feedbackisnullwhen 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).
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). Providedocuments(up to 50 strings, max 255 characters each) and/ormessage(max 2000 characters). Omitted fields keep their existing values. Send explicitdocuments: []ormessage: ""to clear that field. An empty request is rejected with400. - Saving feedback sets
statustoOPENandresolved_attonull. - Mark feedback done with Resolve Application Feedback (
PATCH /applications/{applicationId}/feedback/resolve). It takes no request body, preservesdocumentsandmessage, and setsstatustoRESOLVEDwithresolved_atandupdated_attimestamps. - Resolving already resolved feedback succeeds without changing timestamps or sending another webhook.
404means the application is inaccessible or no feedback exists.409means the feedback changed during resolve — retry the resolve.- Feedback saved before statuses were introduced reads as
OPENwithresolved_at: null. - Saving or first resolving feedback sends an
APPLICATION_UPDATEDwebhook. Fetch the application to read the updatedfeedbackobject.
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: apropertyId 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 (The response returns a short-lived
GET /landlords/token) from your server with your API access token. No request body is required.- Production
- Sandbox
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 The SDK embeds the report automatically. Standard callbacks such as
propertyId and applicationId are required — the report will not render if either is missing.onLoad, onError, and onCancel, and the height option work the same as for tenant sessions.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.
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.
FINANCIAL_ANALYSIS_SUCCESS or FINANCIAL_ANALYSIS_FAILURE 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.
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.