Difference between revisions of "API done contacts"
(→Writing) |
|||
| (12 intermediate revisions by one other user not shown) | |||
| Line 1: | Line 1: | ||
[[API Details|Go to API overview]] | [[API Details|Go to API overview]] | ||
| − | These are completed actions. | + | These are completed actions, which are equivalent to the top half of Record a Contact in the web application. |
| + | |||
| + | ==Reading== | ||
| + | |||
| + | A list of selectable fields can be found using: | ||
| + | [GET] https<nowiki/>://api.dizions.co.uk/v2/done_contacts/selectable_fields | ||
| + | |||
| + | A list of fields available as metrics can be found using: | ||
| + | [GET] https<nowiki/>://api.dizions.co.uk/v2/done_contacts/metrics | ||
| + | |||
| + | Typical filters are dates, projects and (in a branch system), branches, e.g. | ||
| + | [GET] https<nowiki/>://api.dizions.co.uk/v2/done_contacts/project/3;5;7/date/2023-01-31,2023-12-31/branch/4;6;8 | ||
| + | |||
| + | For a full list of filters, use: | ||
| + | [GET] https<nowiki/>://api.dizions.co.uk/v2/done_contacts/filterable_fields | ||
| + | |||
| + | ==Writing== | ||
| + | |||
| + | To create a done_contact, use the referral number: | ||
| + | |||
| + | [POST] https<nowiki/>://api.dizions.co.uk/v2/done_contacts/referral/127 | ||
| + | |||
| + | The body must contain all of the following keys for creation: | ||
| + | user | ||
| + | stage | ||
| + | start_date | ||
| + | end_date | ||
| + | description | ||
| + | |||
| + | Optionally, you can also add: | ||
| + | travel_time | ||
| + | travel_mileage | ||
| + | transport_method | ||
| + | contact_type | ||
| + | priority | ||
| + | |||
| + | This will return the id, which can be used for editing, by adding at least one of the required or optional keys, like this: | ||
| + | |||
| + | [PUT] https<nowiki/>://api.dizions.co.uk/v2/done_contacts/456 | ||
| + | |||
| + | |||
| + | The done_contact is also used to complete a due_contact, because conceptually, you are converting a due_contact into a done_contact when completing it. Also see [[API_due_contacts|the page on due_contacts]] | ||
| + | |||
| + | There are various validation rules in the web app to make optional fields compulsory for users of the web app, for example if you require a priority for every referral. These settings are not implemented in the API, as the data avilable to the API caller may be different to user of the web app. The assumption is that the caller will perform its own validation. | ||
Latest revision as of 16:31, 29 November 2024
These are completed actions, which are equivalent to the top half of Record a Contact in the web application.
Reading
A list of selectable fields can be found using:
[GET] https://api.dizions.co.uk/v2/done_contacts/selectable_fields
A list of fields available as metrics can be found using:
[GET] https://api.dizions.co.uk/v2/done_contacts/metrics
Typical filters are dates, projects and (in a branch system), branches, e.g.
[GET] https://api.dizions.co.uk/v2/done_contacts/project/3;5;7/date/2023-01-31,2023-12-31/branch/4;6;8
For a full list of filters, use:
[GET] https://api.dizions.co.uk/v2/done_contacts/filterable_fields
Writing
To create a done_contact, use the referral number:
[POST] https://api.dizions.co.uk/v2/done_contacts/referral/127
The body must contain all of the following keys for creation:
user stage start_date end_date description
Optionally, you can also add:
travel_time travel_mileage transport_method contact_type priority
This will return the id, which can be used for editing, by adding at least one of the required or optional keys, like this:
[PUT] https://api.dizions.co.uk/v2/done_contacts/456
The done_contact is also used to complete a due_contact, because conceptually, you are converting a due_contact into a done_contact when completing it. Also see the page on due_contacts
There are various validation rules in the web app to make optional fields compulsory for users of the web app, for example if you require a priority for every referral. These settings are not implemented in the API, as the data avilable to the API caller may be different to user of the web app. The assumption is that the caller will perform its own validation.
