Skip to main content

Avni Destination

Nexla's bi-directional connectors allow data to flow both to and from any location, making it simple to create a FlexFlow data flow that sends data to an Avni location.
avni_api.png

Avni

Create an Avni Destination​

  1. Click the + icon on the Nexset that will be sent to the Avni destination, and select the Send to Destination option from the menu.

  2. Select the Avni connector from the list of available destination connectors. Then, select the credential that will be used to connect to the Avni organization, and click Next; or, create a new Avni credential for use in this flow.

  3. In Nexla, Avni destinations can be created using pre-built endpoint templates, which expedite destination setup for common Avni endpoints. Each template is designed specifically for the corresponding Avni endpoint, making destination configuration easy and efficient.
    • To configure this destination using a template, follow the instructions in Configure Using a Template.

    Avni destinations can also be configured manually, allowing you to send data to Avni endpoints not included in the pre-built templates or apply further customizations to exactly suit your needs.
    • To configure this destination manually, follow the instructions in Configure Manually.

Configure Using a Template​

Nexla provides pre-built templates that can be used to rapidly configure destinations to send data to common Avni endpoints. Each template is designed specifically for the corresponding Avni endpoint, making destination setup easy and efficient.

  • To configure this destination using a template, select the endpoint to which data will be sent from the Endpoint pulldown menu. Then, click on the template in the list below to expand it, and follow the instructions to configure additional endpoint settings.

    Create or Update Subject

    This endpoint creates a new subject in Avni or updates an existing subject via UUID-based idempotent upsert. Use it to register beneficiaries from upstream systems (a CRM, an external registration form, or a partner system of record) or to keep subject attributes in sync with an authoritative source.

    • Each record sent to this endpoint must include the Avni fields required to identify and describe a subject — at minimum a uuid (for idempotent upsert), a subjectTypeName (the subject type, such as Individual or Household, configured in Avni), the registration date, and the address-level UUID. Required observations vary by subject type and are defined in the Avni registration form.
    • The full Nexset record is sent as the JSON body of the POST /api/subjects call. Use a Nexla transform to reshape upstream attributes into the field names expected by Avni.

    Avni's POST operation is idempotent — supplying the same uuid updates the existing record rather than creating a duplicate. Generate UUIDs once on the source side and persist them so subsequent syncs route to the same Avni subject. For payload reference, see the Avni API Guide.

    Create or Update Enrolment

    This endpoint creates a new program enrolment for a subject or updates an existing enrolment via UUID-based idempotent upsert. Use it to register subjects into a longitudinal program (for example, antenatal care or a livelihoods scheme) from an upstream system.

    • Each record must include the enrolment uuid, the parent subjectUUID (the subject the enrolment belongs to), the program name, and the enrolmentDateTime. Program-specific enrolment observations should match the program's enrolment form definition in Avni.
    • The full Nexset record is sent as the JSON body of the POST /api/enrolments call.

    An enrolment must reference an existing subject in Avni — ensure that the upstream subject has been synced via Create or Update Subject (or already exists in Avni) before sending an enrolment with the matching subjectUUID.

    Create or Update Encounter

    This endpoint creates a new general subject encounter (one that is not part of a program) or updates an existing encounter via UUID-based idempotent upsert. Use it to record ad-hoc visits or non-programmatic interactions captured in an external system.

    • Each record must include the encounter uuid, the parent subjectUUID, the encounterType, and the encounterDateTime. Encounter observations should align with the encounter form definition in Avni.
    • The full Nexset record is sent as the JSON body of the POST /api/encounters call.

    To record visits that occur within an enrolled program (such as antenatal-care visits), use the Create or Update Program Encounter endpoint instead.

    Create or Update Program Encounter

    This endpoint creates a new program encounter (a visit within an enrolment) or updates an existing program encounter via UUID-based idempotent upsert. Use it to push program-visit data — such as scheduled antenatal-care visits or growth-monitoring checks — from an upstream system into Avni.

    • Each record must include the program-encounter uuid, the parent programEnrolmentUUID (the enrolment the visit belongs to), the encounterType, and the encounterDateTime. Visit observations should align with the program-encounter form definition in Avni.
    • The full Nexset record is sent as the JSON body of the POST /api/programEncounters call.

    A program encounter must reference an existing enrolment in Avni — sync upstream enrolments via Create or Update Enrolment before sending program encounters that reference them.

    Create Task

    This endpoint creates a task in Avni. Tasks can only be created via the external API and are surfaced to frontline workers in the Avni app — use this endpoint to drive action items from upstream systems, such as automated outreach lists, escalations, or follow-up calls.

    • Each record must include the task name, the taskTypeName, and the relevant scheduling/assignment fields expected by your Avni task type. Avni supports two task types: call tasks (used for outbound calls to a subject) and openSubject tasks (used to direct a worker to open a specific subject record).
    • The full Nexset record is sent as the JSON body of the POST /api/tasks call. Use a Nexla transform to shape upstream attributes into the field names expected by Avni's task schema.

    Tasks are write-only via this endpoint — once created, their lifecycle (in-progress, completed, etc.) is managed inside the Avni app by frontline workers. Use the List Tasks source endpoint to monitor task status downstream.

Configure Manually​

Avni destinations can be manually configured to send data to any valid Avni external API endpoint.

Using manual configuration, you can also configure Nexla to automatically send the response received from the Avni API after each call to a new Nexla webhook data source — useful for capturing the assigned IDs and UUIDs returned by Avni's idempotent upsert endpoints.

API Method​

  1. To manually configure this destination, select the Advanced tab at the top of the configuration screen.

  2. Select the API method that will be used for calls to the Avni API from the Method pulldown menu. Avni's external write endpoints use POST for idempotent create-or-update operations on subjects, enrolments, encounters, program encounters, and tasks.

Data Format​

  1. Select the format in which the Nexset data will be sent to the Avni API from the Content Format pulldown menu. Avni's external API accepts JSON, so application/json is the appropriate selection. Nexla will automatically convert the Nexset data to JSON for each API call.

API Endpoint URL​

  1. Enter the URL of the Avni API endpoint to which you want to send the Nexset data in the URL field. All Avni external API URLs are of the form <base_url>/api/<resource> — for example, https://app.avniproject.org/api/subjects or https://app.avniproject.org/api/programEncounters. For idempotent upsert, the UUID is included in the JSON body of the request rather than the URL path.

Request Headers​

Optional

  • If Nexla should include any additional request headers in API calls to this destination, enter the headers & corresponding values as comma-separated pairs in the Request Headers field (for example, header1:value1,header2:value2).

    You do not need to include any headers already present in the credentials. The AUTH-TOKEN header carrying the Avni JWT and the Content-Type: application/json header are added automatically based on your Avni credential and the selected content format.

Exclude Attributes from the Call​

Optional

  • If any record attributes in the Nexset should be omitted when sending data to this Avni destination, select the attributes from the Exclude Attributes pulldown menu. This is useful for stripping internal Nexla bookkeeping fields or upstream metadata that does not match the Avni schema.

  • Any number of attributes can be selected for exclusion, and all excluded attributes will be shown in the field. To remove an attribute from the list, click the X icon next to the attribute name.

Record Batching​

Optional

The Avni external API expects one entity per request (one subject, one enrolment, one encounter, etc.) for its idempotent upsert endpoints, so the pre-built templates send each record in its own API call (batch.mode: false). Record batching should only be enabled if you are calling a custom Avni endpoint that accepts arrays of entities.

  1. If records should be sent to this destination in batched API calls, check the box next to Would you like to batch your records together? to enable record batching.

  2. Enter the maximum number of records that should be batched together in a single API call in the Batch Size field. By default, this value is set to 100.

  3. Select the algorithm that will be used to group records into batches from the Grouping Algorithm pulldown menu. The sample request shown in the panel on the right will be updated to reflect the current batching settings.

Response Webhook​

Optional

Nexla can automatically send the response received from the Avni API after each call to a new Nexla webhook data source. This is particularly useful for capturing the IDs and UUIDs Avni assigns when subjects, enrolments, encounters, program encounters, or tasks are created — those values can then be joined back to the upstream records for downstream tracking.

  • To enable this option, check the box next to Would you like to process the API response as a Nexla Webhook source?.

Sample Request Payload​

Sample request payloads containing a portion of the Nexset data that will be sent to the Avni API endpoint based on the current settings are shown in the Sample Payload panel on the right. These samples can be referenced to ensure that the destination and request settings are correctly configured.

  • Click on a sample request payload to expand it and view the complete payload content.

  • Sample payloads are automatically updated with each setting change, making it easy to verify that changes achieve the desired effect.

Endpoint Testing (Manual Configuration)​

After all endpoint settings have been configured, Nexla can send a test payload to the Avni API to ensure that the destination is configured correctly.

  1. To send a test payload, select the Test button at the top of the Sample Payload panel, and click on a listed sample payload to expand it.

  2. If any modifications to the sample payload are needed, make the necessary changes directly within the sample window.

  3. Click the Send Test Data button at the top of a sample payload to send the test payload to the Avni API using the current settings.

Important

Avni's POST endpoints are idempotent and will create or modify production data. Use a non-production Avni environment (or a dedicated test organization) when sending test payloads, and verify the assigned UUIDs in the Avni web console before activating the destination.

Save & Activate the Destination​

  • Once all endpoint settings have been configured, click the Done button in the upper right corner of the screen to save and create the destination. To begin sending the Nexset data to Avni, open the destination resource menu, and select Activate.

    The Nexset data will not be sent to Avni until the destination is activated. Destinations can be activated immediately or at a later time, providing full control over data movement.