Step-by-Step Integration Guide

The logic for how you consume the DateCheck service is ultimately determined by you, as you have the best understanding of your specific needs. However, to help you get started, here is a suggested step-by-step guide on how to use the service in conjunction with the separate GetData REST API.

When dealing with a new customer who has no previous credit history in your system:

Make an API call to GetData to retrieve basic information, such as status, name, and address.

Purpose:

• Confirm you have the correct consumer or company
• Verify they are active for trade

Decision Point:

• ✅ If the information confirms their active status → Proceed to Step 2
• ❌ If not active → No further requests necessary, no credit report generated

GET /getdata?searchnumber=5565144408&block=basic
Headers: Authorization: Bearer {token}

Make another API call to GetData to obtain credit information including:

• Income
• Payment remarks
• Debt details
• Score/Rating

Purpose:

• Gather necessary data for making a credit decision
• Establish baseline for future DateCheck comparisons

GET /getdata?searchnumber=5565144408&block=credit
Headers: Authorization: Bearer {token}

Store for Future Reference:

• Date of this credit decision
• Outcome of the credit decision
• All relevant data points used in your decision

When dealing with a returning customer who already has credit history in your system:

Make an API call to DateCheck, using the reference date from the previous GetData request(s).

Purpose:

• Identify if any relevant data has changed since your last credit check
• Avoid unnecessary credit checks and disclosure letters

GET /datecheck/company?searchnumber=5565144408&referencedate=2024-01-01
Headers: Authorization: Bearer {token}

Response Analysis: The response will contain zero, one, or more change codes along with the dates they occurred.

If no change code is returned, you can confidently:

✅ Provide the same credit decision as outlined in Step 2
✅ Avoid additional calls to GetData
✅ Avoid triggering letters of disclosure
✅ Save time and costs

If one or more change codes are returned, analyze the types of changes:

If the changes are only of basic type (marked with * in Change Categories):

{
  "report": [
    {
      "code": "CON",
      "description": "Kontakt information",
      "changeDate": "2024-06-15T00:00:00"
    },
    {
      "code": "BOA",
      "description": "Styrelse",
      "changeDate": "2024-06-15T00:00:00"
    }
  ]
}

Action:

• ✅ Retrieve updated information using GetData basic block
• ✅ No letters of disclosure will be sent
• ✅ Update your internal records
• ✅ Re-evaluate credit decision if needed (usually not required for basic changes)

GET /getdata?searchnumber=5565144408&block=basic
Headers: Authorization: Bearer {token}

If the changes include credit type categories:

{
  "report": [
    {
      "code": "RAT",
      "description": "Rating",
      "changeDate": "2024-06-15T00:00:00"
    },
    {
      "code": "DEP",
      "description": "Betalningsanmärkning E-Mål/Tredskodom",
      "changeDate": "2024-06-13T00:00:00"
    },
    {
      "code": "CON",
      "description": "Kontakt information",
      "changeDate": "2024-06-10T00:00:00"
    }
  ]
}

Action:

1. Evaluate Relevance: Determine which changes impact your credit decision

   • Is "Rating" (RAT) critical to your decision? → Yes, fetch it
   • Is "Taxation" (ASS) used in your logic? → If no, skip it

2. Selective Updates:

   • Only call GetData with credit block for relevant change types
   • This minimizes disclosure letters

3. Implement Smart Logic:

   If (RAT or DEP or DAP or SCO changed) AND (used in our credit logic):
       Call GetData with credit block
       Update internal records
       Re-evaluate credit decision
       Send disclosure letter (if applicable)
   Else:
       Use existing credit decision

If your logic manages data updates correctly, you can optimize by setting the reference date to the previous DateCheck request instead of the latest credit decision.

Initial Credit Decision: 2024-01-01
DateCheck Call 1: referencedate=2024-01-01 → Returns changes since Jan 1
DateCheck Call 2: referencedate=2024-01-01 → Returns same changes again

Problem: You'll keep seeing the same changes even though you've already processed them.

Initial Credit Decision: 2024-01-01
DateCheck Call 1: referencedate=2024-01-01 → Returns changes since Jan 1
                  Store: last_datecheck = 2024-03-15

DateCheck Call 2: referencedate=2024-03-15 → Returns only NEW changes since Mar 15
                  Store: last_datecheck = 2024-06-20

Benefit: You only see new changes since your last check, avoiding duplicate processing.

Diagram summary (accessibility): For a new customer, call GetData basic block and check status; if inactive, reject without further action. If active, call GetData credit block, make a credit decision, and store the decision date. For a returning customer, call DateCheck with the stored reference date. If no changes are detected, reuse the previous decision. If changes are detected, evaluate whether they are basic or credit type: basic-only changes trigger a GetData basic block call and a records update with optional re-evaluation; credit changes are assessed for relevance to decision logic, and if relevant trigger a GetData credit block call, records update, and re-evaluation.

1. Always start with basic block for new customers to verify active status
2. Store decision dates and outcomes for future reference
3. Use DateCheck before fetching credit data for returning customers
4. Analyze change types before deciding on GetData call type
5. Implement selective updates to minimize disclosure letters
6. Track DateCheck calls to avoid recurring change codes
7. Document your logic for which changes trigger credit checks
8. Test thoroughly in sandbox environment before production

The Creditsafe Integration team is available to assist with implementation questions:

📧 Email: integration@creditsafe.se

For sales-related questions or service agreements, contact your Creditsafe account manager.