Project Description
I’m ready to connect our SmartOLT provisioning platform with our in-house Netzur CRM through their respective REST APIs. The goal is to keep customer data perfectly aligned, fire automated actions the moment an event occurs on either side, and push instant SMS or WhatsApp notifications where required.
Core scope
• Data syncing – SmartOLT customer records (name, address, service plan, ONU details) must stay in two-way sync with the corresponding customer objects in Netzur.
• PPPoE credentials – username and password fields need to travel alongside the standard customer information so new activations or credential changes propagate automatically.
• Trigger-based actions – when a new ONU is provisioned, a plan is upgraded, or a customer is suspended/unsuspended, the integration should post back to Netzur, update the status, and optionally create a CRM activity.
• Messaging layer – selected events (welcome, suspension, restoration, upcoming renewal) must invoke our existing SMS & WhatsApp gateways. A simple template engine is already available; the integration only needs to hit its endpoints with the correct payload.
Technical notes
Both systems expose full JSON REST APIs with token-based auth and detailed documentation that I’ll supply immediately. I have server access (Ubuntu 22.04, Node.js and Python installed) but I’m open to your preferred language or iPaaS tool as long as the code is clean, version-controlled, and accompanied by setup instructions.
Deliverables
1. Source code / scripts or iPaaS configuration.
2. Environment variables file with sample keys.
3. Postman (or similar) collection covering each endpoint used.
4. Readme detailing deployment, cron/webhook configuration, and rollback steps.
5. Short handover call or recorded walkthrough.
Acceptance criteria
• Create, update, and delete operations remain consistent between SmartOLT and Netzur after 500+ record test.
• Typical event fires within five seconds and sends the correct WhatsApp/SMS message.
• Error handling writes to a log and retries three times before flagging a failure.
If you’ve integrated telecom or ISP provisioning systems before, that’s a bonus. Let me know your proposed timeline and tech stack and I’ll provide the API docs right away.