Knit is an event driven platform that helps out your dev teams in building native integrations with minimal effort. Knit does this by exposing an embeddable white-labelled UI component that can be embedded in your front end code. This component allows your end users to securely authorize integrations. Further, you can sync data from these integrations using Knit's APIs and common data models .
One common data model for each category helps your developers expedite integration releases. Further, our white-labelled UI component can be customized to match your app's design palette.
Want to see Knit in action? Click here to get started. Want to understand more about Knit? Read on!
Don't call us, we will make sure your data is delivered to you
With event driven micro-services architectures on the rise, the push model is definitely easier to work with and scale vs a pull model.
In a pull model, your servers are busy making calls to the data providers like HRIS, Payroll systems etc to get data. In order to do so, you'd need to create a polling infra. If you're doing so for 10-15 batch jobs, perhaps it is manageable. But imagine doing this for hundreds, even thousands, of jobs. The problem gets harder. Further, if there is no new data to report, you wasted your compute resources on an empty call.
Now compare this with the push model. Typically you'd need to subscribe to certain events by registering a webhook. When the event happens, the data providers would notify you with appropriate payload on the registered destination url. You don't have to manage any polling infra, neither would you waste compute resources on inconsequential calls.
At Knit, we love the push model. All data syncs, at Knit, happen through webhooks.
At Knit, syncs are the preferred way for reading data from source applications. Once you create a Knit sync, we will always push data to your endpoint.
You need to tell Knit which data category to fetch data for and what all models to get and where to send data to, and that's it! We will poll the data provider system frequently and send data models to you on the registered webhook destination.
Syncs start automatically
Once your user integrates with an app successfully, we'll immediately trigger a sync for it and start sending you the data for the subscribed data models.
Once a sync has been setup, it will never be stopped unless you pause it via the dashboard.
The first sync that happens after an app is integrated is called Initial Sync. Thereafter, Knit will do Delta Sync to discover data changes on a regular frequency. Irrespective of the type of sync, you will get data in the sync webhook as and when we discover any data of interest for you. But broadly you can expect 5 kinds of events:
|Type of event
|A new record was encountered. Ex: A new employee entry in HRIS
|An existing record was modified. Ex: An existing employee's title was changed
|An existing record was deleted or is inactive. Ex: An existing employee exited from the org.
|Marks the processing of a sync run. This event will contain a count of events emitted. Use this for book-keeping only, don't rely on it's ordering as Knit doesn't guarantee event ordering.
|Marks the end of consumption of all the events that were triggered in a particular sync run. This event is guaranteed to be delivered after all the events in a sync run have been consumed/acknowledged. Use this a signal to start any downstream workflow at your end.
Make sure your code can handle these events on your registered webhook.
- Knit will try to deliver the event on the webhook registered while sync setup.
- Knit expects an HTTP response with status code 200 as acknowledgement of message consumption.
- Knit will retry message delivery over 4 days in case of message delivery failures. After the 4th day, Knit will not retry delivery on the webhook. However, you can manually trigger the sync flow for a record through our web app.
- Knit will send an additional event of type
sync.events.allEmittedonce all the events in run have been emitted. This event will contain details about the count of events emitted. Use this to track event delivery from Knit only. Do not rely on the order in which the event is received.
- Once all the events have been consumed, Knit will send another event with type
sync.events.allConsumedto mark the completion of an sync run.
Send a HTTP response with status code 200 to acknowledge an event.
Another important, but often ignored, aspect of an Integration is its management. Integration management is broadly concerned with two important questions:
- Is the integration working as expected?
- What all data were we able to sync via this integration
Knit tries to solve for both these asks in great detail.
As soon as your user provides integration details, Knit starts validating the user's credentials. If things are all good, you will receive a success payload from the UI component itself. If the integration has errors, Knit will not return the errors but your user can also see a descriptive error message and resolution on Knit's UI component. This will enable your user to self fix common integration issues like admin credentials needed or invalid username/password and many more.
Now for the second concern, our web app can be used for auditing each sync run that happens on Knit. On the app, you can see what all data was synced, when did the sync happen, what all models were synced and what were the issues if any.
At Knit, data security is our foremost concern. Thus we decided to not store any user data in our DB. That's why
- Knit's write APIs are pass through in nature.
- Knit's sync callbacks check for data changes and normalise data on the fly before dispatching data on webhooks.
- Data is encrypted at rest(AES-256) and in transit(TLSv1.2)
- SOC2, GDPR, ISO27001, HIPAA Ready
Knit does not store any of your user's data in its DB.
Once an app has been integrated and a sync has been setup, you can expect data on the registered webhook in a matter of seconds. Typically a sync will get over in minutes. But this is all subject to API rate limits and timeouts.
The best way to track the completion of a sync run is either receipt of
sync.events.allConsumed event or matching the number of events actually received by your webhook and comparing it with count of emitted events in
sync.events.allEmitted event payload.
Empower your CX teams while letting your dev teams do more of the important stuff. Through, Knit's web app, your CX teams can audit sync runs visually and answer any of your user's questions around integration.
Our embedded white labelled UI component can be fully customized to match the design palette of your app.
Updated 9 months ago