API integrations with logs, retry and duplicate protection
An integration is not just a REST request. You need mapping, logs, error handling, retry, duplicate protection and a clear exchange status.
When you need it
Sync works "sometimes"
Duplicates appear
Data diverges between systems
No exchange history
The error is not visible to the user
A CRM must be connected to an external service
What's included
Bitrix24
1C
MoySklad
TrustMe
PKB
ADATA
HeadHunter
Huntflow
Telegram
WhatsApp
Asterisk
How I work
- 1Analysis of the API and exchange points
- 2Mapping and deduplication rules
- 3Implementation with logs and retry
- 4Test exchange scenario
- 5Monitoring and exchange status
Why integrations break
No idempotency
No duplicate protection
No retry
No payload logs
Secrets end up in logs
No status mapping
API errors are ignored
Data updated directly without checks
No queue
No manual retry
How I do it
request_id
external_id
status map
masked logs
retry / backoff
queue
validation
dry-run
manual retry
error dashboard
What the client gets
- Data is not lost
- Duplicates are not created
- The exchange does not fail silently
- Clear logs of incoming/outgoing requests
- The ability to retry a failed operation
Risks and limits
- I am not responsible for failures on the side of external services and providers
- I mask secrets and do not log tokens
- First a test environment, then production
Approximate work formats
One integration
fixed from a sum
Hour package
10 / 25 / 50 / 100
Exchange stabilization
Integration Rescue
Retainer
by agreement
If the project is old, without logs or documentation, with unknown integrations or production risks — an audit comes first. Otherwise any exact estimate is just guessing.
What I will need to work
- Minimal access to the system: Bitrix24 / repository / staging
- Access to logs if the task is about errors
- Description of the business scenario and expected result
- For integrations: API docs, test keys, payload examples
How I handle access
- I do not ask for excessive rights
- Tokens and keys are never sent to public chats
- For production changes — a separate user and a backup when there is risk
- After completion access can be revoked
Related cases
FAQ
How do you protect against duplicates?
Mapping + rules to find existing records + idempotent operations.
What about secrets?
They are encrypted (Crypt); only masks reach the logs.
Can a failed exchange be retried?
Yes: retry and manual retry with a clear operation status.
Not sure where to start?
Just describe the problem. I will study the current solution, assess the risks and propose implementation options.