Guides

Continuous Sync

Regular data updates between CRM and Rentix

After initial sync, set up regular updates so CRM changes are reflected on Rentix.

Sync only changed listings. Resending all listings every time is an inefficient use of the API.

Sync Approaches

You can send data to Rentix anytime and in any convenient way:

Immediately on change — send data when saving in CRM
Periodically — run sync on schedule
In batches — accumulate changes and send as a group via bulk endpoint

The choice depends on your architecture and requirements for update speed.

Scheduled Sync

Periodically query changed listings from your CRM and send them to Rentix.

Logic

Store the time of last successful sync
Query changed listings from CRM (starting from that time)
Send changes to Rentix via bulk endpoint
Update the last sync time

Example Request

const response = await fetch('https://crm.rentix.md/api/v1/listings/bulk', {
  method: 'POST',
  headers: {
    'Authorization': 'ApiKey YOUR_API_KEY',
    'Content-Type': 'application/json'
  },
  body: JSON.stringify({
    operations: [
      {
        op: 'upsert',
        externalId: 'apt-123',
        announcementValue: 45000,
        announcementStatus: 'active'
      },
      {
        op: 'upsert',
        externalId: 'apt-456',
        announcementStatus: 'hidden'
      }
    ]
  })
});

const result = await response.json();
console.log(`Updated: ${result.summary.succeeded}/${result.summary.total}`);

curl -X POST https://crm.rentix.md/api/v1/listings/bulk \
  -H "Authorization: ApiKey YOUR_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "operations": [
      {
        "op": "upsert",
        "externalId": "apt-123",
        "announcementStatus": "active",
        "announcementValue": 45000
      },
      {
        "op": "upsert",
        "externalId": "apt-456",
        "announcementStatus": "hidden"
      }
    ]
  }'

$data = [
  'operations' => [
    [
      'op' => 'upsert',
      'externalId' => 'apt-123',
      'announcementValue' => 45000,
      'announcementStatus' => 'active'
    ],
    [
      'op' => 'upsert',
      'externalId' => 'apt-456',
      'announcementStatus' => 'hidden'
    ]
  ]
];

$ch = curl_init('https://crm.rentix.md/api/v1/listings/bulk');
curl_setopt($ch, CURLOPT_POST, true);
curl_setopt($ch, CURLOPT_POSTFIELDS, json_encode($data));
curl_setopt($ch, CURLOPT_HTTPHEADER, [
  'Authorization: ApiKey YOUR_API_KEY',
  'Content-Type: application/json'
]);
curl_setopt($ch, CURLOPT_RETURNTRANSFER, true);
$response = curl_exec($ch);

Use announcementStatus: "hidden" for listings deleted in your CRM.

Event-Based Sync

When a listing changes in CRM, send data to Rentix immediately.

For Single Listing

const response = await fetch('https://crm.rentix.md/api/v1/listings', {
  method: 'PUT',
  headers: {
    'Authorization': 'ApiKey YOUR_API_KEY',
    'Content-Type': 'application/json'
  },
  body: JSON.stringify({
    externalId: 'apt-123',
    announcementValue: 46000,
    announcementDescription: 'Updated description'
  })
});

const result = await response.json();

curl -X PUT https://crm.rentix.md/api/v1/listings \
  -H "Authorization: ApiKey YOUR_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "externalId": "apt-123",
    "announcementValue": 46000,
    "announcementDescription": "Updated description"
  }'

$data = [
  'externalId' => 'apt-123',
  'announcementValue' => 46000,
  'announcementDescription' => 'Updated description'
];

$ch = curl_init('https://crm.rentix.md/api/v1/listings');
curl_setopt($ch, CURLOPT_CUSTOMREQUEST, 'PUT');
curl_setopt($ch, CURLOPT_POSTFIELDS, json_encode($data));
curl_setopt($ch, CURLOPT_HTTPHEADER, [
  'Authorization: ApiKey YOUR_API_KEY',
  'Content-Type: application/json'
]);
curl_setopt($ch, CURLOPT_RETURNTRANSFER, true);
$response = curl_exec($ch);

For Multiple Listings

If your CRM accumulates changes or generates batch events, use the bulk endpoint.

Combined Approach

For maximum reliability, combine both approaches:

Events — for instant updates
Periodic check — for catching missed changes

The periodic check serves as a fallback mechanism in case of event system failures.

Recommendations

Send Only Changes

{
  "operations": [
    {
      "op": "upsert",
      "externalId": "apt-123",
      "announcementValue": 45000
    }
  ]
}

Rentix updates only the passed fields. If only the price changed — send only the price.

Use Bulk for Mass Updates

Instead of 100 separate requests, send one bulk request with 100 operations. Maximum — 100 operations per request.

Handle Partial Errors

The bulk endpoint returns a result for each operation:

{
  "summary": {
    "total": 3,
    "succeeded": 2,
    "failed": 1
  },
  "results": [
    { "externalId": "apt-123", "success": true },
    { "externalId": "apt-456", "success": true },
    { "externalId": "apt-789", "success": false, "error": "Invalid status" }
  ]
}

Failed operations don't affect successful ones. Handle errors and retry failed operations separately.

Error Handling

Rate Limiting

On 429 Too Many Requests, wait and retry. The Retry-After header indicates recommended wait time.

Temporary Errors

5xx errors are usually temporary. Retry the request after a few seconds.

Validation Errors

400 Bad Request errors require fixing data. Check the error message and fix data before retrying.

Monitoring

We recommend tracking:

Metric	Description
Updated listings count	How many listings were successfully synced
Error count	How many operations failed
Last sync time	When data was last synced
Sync latency	Time between CRM change and Rentix update

Initial Sync

Upload all listings from CRM on first connection