Accounts
Accounts are entities that are involved in transaction in the system. They could be a sender of the money or a destination that receives money.
Accounts in Nuflow are Entities / counter parties that send money or recieve money (Please do not confuse them with Bank accounts)
- Customer (usually who send money)
- Supplier / Provider or Partner (usually who receive money
Every account should have a unique identifier in the database. Nuflow provides the ability to associate two identfiers with an account:
This is a required identifier which must be provided while creating an account, its usually the same as the identifier in your database.
It's recommended to keep this same or similar to the unique identifier for the entity in your database for easy identification.
Customer with database Id 1001 should be created with the same client_identifier (1001) for easy identification.
This is another identifier which Nuflow associates with an account. This is automatically created by nuflow and used internally within the nuflow platform. Nuflow recommends that each account identifier have a namespace with a unique UUID/ integer or a string like this: namespace:<unique-id> for readability.
This identifier is optional and is automatically generatedwith the following format category:client_identifierwhere cateogry is the category of the account defined by the user and client_identifieris the unique client identifier defined above.
For example: Customer with client identifier 1001 is created with nuflow_identifier as: "customer:1001"
Nuflow identifiers must respect the following regex pattern ^[a-zA-Z_]+[a-zA-Z0-9_:]*$which means the identifier can:
- Include lowercase letters a-z and upper case letters A-Z
- Include digits 0-9 but cannot begin with them
- Only include _ and : as special characters
- Can be extended with all tokens following the same format
Client identifiers can:
- Include lowercase and uppercase letters
- Include and begin with digits
- Only include _ and : as special characters
- Riders: Each unique rider could have an identifier like rider:<id> :
- rider:001
- rider:002
- Suppliers with database id's
- supplier:55
- supplier:56
- Merchants with hierarchy
- kfc:sg:22
- kfc:sg:23
- kfc:sg:24
- mcd:sg:25
- Contractors with UUID's where - are replaced with _
- contractor:28a2d474_1fcd_11ee_be56_0242ac120002
- Employees:
- employee:emp_code_8800
Smart usage of Account identifier can denote a hierarchy as well. Using hierarchy can help you get transactional analytics.
Example: Let's define a hierarchy for a merchant kfc with multiple stores in asia/singapore
- kfc:asia
- kfc:asia:sg
- kfc:asia:sg:store_001
- kfc:asia:sg:store_002
- kfc:asia:sg:store_003
Note: The account identifier is separated by colon : for a meaningful hierarchy
We highly recommend that you utilise smart account identifiers for a meaningful namespace and a hierarchy.
The base URL for all accounts API requests is /api/v1/ops/accounts/
All requests must be authenticated using an API key.

Accounts can be created and updated in bulk using the bulk API endpoints. The error respone for the bulk apis also provides the index of the object which led to the error through the index key in the detaillist.
Currently, only commit all or none strategy is supported by the bulk APIs which means either all the accounts will be created/updated or none of them will in case of an error.

