# File Deliveries

## Set-up 

This information is required when using a GET request to fetch File Deliveries via the Ideon API.

/coverage\_periods/{id}/file\_deliveries

| Ideon | Usage & Mapping                                                                                                                                                                                               |
| ----- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| id    | <p>In the request url, provide the unique id for the given coverage period. </p><p></p><p>This is the coverage period for which Organization Name, Carrier and Time Period you would like to view files. </p> |

## Response&#x20;

This is the information returned on a `file_deliveries` response:

<table><thead><tr><th width="374">Ideon</th><th>Usage &#x26; Mapping</th></tr></thead><tbody><tr><td>id</td><td><p>In the request url, provide the unique id for the given coverage period. </p><p></p><p>This is the coverage period for which Organization Name, Carrier and Time Period you would like to view files. </p></td></tr><tr><td>file_name</td><td>This is the file name that Ideon created for the delivery. File names are often in a specific, required carrier format.</td></tr><tr><td>sent_at</td><td>This is a timestamp is when Ideon delivered the file to the Carrier.  </td></tr></tbody></table>

## Implementation Paths

Here are the possible ways to use the `file_deliveries` endpoints:

### Example 1: Audit for Expected File Deliveries

Objective: Understand if any carrier files expected were not sent as expected, and when they were sent to the carrier.

This implementation uses:

* GET /coverage\_periods/{id}
* GET /coverage\_periods/{id}/file\_deliveries

1. GET information for a given coverage period
   1. distribution\_format
   2. state
   3. next\_send\_time
2. Poll or watch for file\_deliveries on that coverage period
   1. Exclude:
      1. coverage periods with `distribution_format` = `api`
      2. coverage periods with any state ***other than*** `production`
   2. For each, send a request to GET /coverage\_periods/{id}/file\_deliveries
   3. Note and display any files that did not have a corresponding delivery

### Example 2: View of File Delivery and Summary of Sent Coverages

Objective: Serve up information about a given file delivery, and the members updated&#x20;

This implementation uses:

* GET /coverage\_periods/{id}
* GET /coverage\_periods/{id}/file\_deliveries
* GET /file\_deliveries/{id}/coverage\_transmissions

1. GET information for a given coverage period
   1. distribution\_format
   2. state
   3. next\_send\_time
2. Poll or watch for file\_deliveries on that coverage period
   1. Exclude:
      1. coverage periods with `distribution_format` = `api`
      2. coverage periods with any state ***other than*** `production`
   2. For each, send a request to GET /coverage\_periods/{id}/file\_deliveries
3. Note and display any files that did not have a corresponding delivery
4. GET coverage transmissions for each delivery
   1. This response includes the coverages included on the file delivery, and can allow you to audit or mark members as Delivered.
5. Using the above information, for delivered files you can construct a view that:
   1. shows the Expected Delivery Date/time&#x20;
   2. shows the Actual Delivery (sent\_at) time&#x20;
   3. shows a list of members that were included and updated from the file delivery&#x20;
   4. shows a list of member that were excluded from the file delivery, for review and confirmation

## Design Questions

The way you use the file deliveries information depends on the needs of your users. Consider using the questions below to evaluate your implementation and how the design fits your user:

* What questions are your users trying to answer when viewing file delivery information?
* What training do they possess to interpret, or troubleshoot?
* Varied audience or mixed experience levels - what level of detail should we show the user?
* Where in the current system are the users seeking information?&#x20;
  * Is there an equivalent process that would be replaced by this new tool?
* What level of security will be required to view the data?
* At what level will the user be viewing this information - member, group, across many groups?
* What data relationships are important to consider in your system?
  * Can this data be updated or created?
  * Is this data view-only?
  * Can this value be null?
* Consider the following relationships implicit in Ideon's API:
  * A coverage period has many file deliveries
  * A file delivery has many coverage transmissions
  * A coverage transmission belongs to a single file delivery
  * A file delivery belongs to many coverage periods&#x20;
    * *Many employers can be delivered at once to a carrier in a multi-group file*

See Additional Documentation for links to our current API documentation.