Will it work with what we already have?
Usually, yes — and usually without a developer. If your system can produce a spreadsheet, that is a working integration on day one. If it can call an API or receive a webhook, there is more available. Below is what actually exists today, and what doesn't.
Getting your data in
Send us a spreadsheet
no codeDownload our template, fill in your properties, paste or upload. No developer, no API key, no integration project. Most portfolios start here and many never need anything else.
Create cases and properties over the API
developerYour system posts a job or a property to ours as it happens. Authenticated with an org API key.
Getting data back out
Read property intelligence on demand
developerQuery a single property, or up to 50 at a time. Partial results are returned rather than failing a whole batch, so one bad reference does not cost you the other 49.
Pull your compliance position
developerThe same compliance calendar your workspace shows, as JSON.
Export to a file
no codePortfolio and compliance exports as CSV or Excel, from the workspace. If your reporting lives in a spreadsheet, this is the shortest path to it.
Batch reads take up to 50 properties per call, and return partial results rather than failing the whole batch — one bad reference does not cost you the other 49.
Events we send
Register an endpoint and we will POST to it when something happens on your account. These are the events that exist today:
job.created— when a case is raised on your account.job.status_changed— when a case moves — accepted, in progress, completed.property.created— when a property is added to your portfolio.compliance.created— when a compliance item is recorded against one of your properties.
Try it before you commit
A sandbox key returns synthetic data only, so your developer can build against the shapes without a contract and without touching anyone's real property record. Sandbox keys are prefixed tlx_test_ and live keys tlx_live_, so you can tell at a glance which one a script is holding.
What we don't do
Your IT team would find these out in week two. Better here.
- Scheduled or automatic file transfer (SFTP, watched folders). CSV import is something a person does when they have a file. There is no scheduled pull. If you need a nightly drop, say so — it is a small piece of work, not a rewrite.
- Two-way sync with your existing system. Data flows in, and data flows out, but nothing reconciles the two automatically. If a record changes on both sides, nothing decides which wins. Treat one system as authoritative.
- Single sign-on (SAML) and SCIM user provisioning. Not built. Your team is invited by email and managed in the workspace, which means joiners and leavers are a manual step on your side rather than something your identity provider handles. If that is a blocker for your security team, tell us — it is a known gap, not a disagreement about whether it matters.
- Inbound webhooks from your system to ours. We send events; we do not receive them. To push data in, your system calls our API or you send a file.
- A published rate limit. There isn't one documented, because we have not needed to enforce one yet. That is honest rather than reassuring — if you are planning high volume, agree it with us first rather than discovering a limit in production.
If the thing you need isn't here, it is worth asking — enterprise@tradelynx.co.uk. Several of the gaps above are small pieces of work rather than architectural problems, and knowing which ones matter to a real customer is how they get prioritised.