Mock sample for your project: Lumminary API

The Benefits Intake API allows authorized third-party systems used by Veteran Service Organizations (VSOs), agencies, and Veterans to digitally submit VA benefits claim documents directly to the Veterans Benefits Administration's (VBA) claims intake process. This API handles documents related to the following benefit claim types:
Compensation
Pension/Survivors Benefits
Education
Fiduciary
Insurance
Veteran Readiness & Employment (VRE)
Board of Veteran Appeals (BVA)
This API also provides submission status updates until documents are successfully established for VBA claim processing, eliminating the need for users to switch between systems to manually check whether documents have been successfully uploaded.
Background
This API provides a secure, efficient, and tracked alternative to mail or fax for VA benefit claim document submissions. Documents are uploaded directly to the VBA so they can be processed as quickly as possible.
Technical overview
The Benefits Intake API first provides an upload location and unique submission identifier, and then accepts a payload consisting of a document in PDF format, zero or more optional attachments in PDF format, and some JSON metadata.
The metadata describes the document and attachments, and identifies the person for whom it is being submitted. This payload is encoded as binary multipart/form-data (not base64). The unique identifier supplied with the payload can subsequently be used to request the processing status of the uploaded document package.
To avoid errors and processing delays, API consumers are encouraged to validate the zipcode,fileNumber, veteranFirstName, veteranLastName and businessLine fields before submission according to their description in the DocumentUploadMetadata model and use the 'businessLine' attribute for the most efficient processing. Additionally, please ensure no PDF user or owner passwords are used in submitted PDFs.
Attachment & file size limits
There is no limit on the number of files a payload can contain, but size limits do apply.
Uploaded documents cannot be larger than 21" x 21"
The entire payload cannot exceed 5 GB
No single file in a payload can exceed 100 MB
Date of receipt
The date that documents are successfully submitted through the Benefits Intake API is used as the official VA date of receipt. However, note that until a document status of received, processing, success, or vbms is returned, a client cannot consider the document received by VA.
A status of received means that the document package has been transmitted, but may not be validated. Any errors with the document package, such as unreadable PDFs or a Veteran not found, will cause the status to change to error.
If the document status is error, VA has not received the submission and cannot honor the submission date as the date of receipt.
Authentication and Authorization
API requests are authorized through a symmetric API token, provided in an HTTP header with name 'apikey'. Request an API key.
Testing in the sandbox environment
In the sandbox environment, the final status of a submission is received and submissions do not actually progress to the central mail repository or VBMS.
Progress beyond the received status can be simulated for testing. We allow passing in a Status-Override header on the /uploads/{id} endpoint so that you can change the status of your submission to simulate the various scenarios.
The available statuses are pending, uploaded, received, processing, success, vbms, and error. The meaning of the various statuses is listed below in Models under DocumentUploadStatusAttributes.
Test data
We use mock test data in the sandbox environment. Data is not sent upstream and it is not necessary to align submitted test data with any other systems' data.
Upload operation
Allows a client to upload a multi-part document package (form + attachments + metadata).
Client Request: POST https://sandbox-api.va.gov/services/vba_documents/v1/
No request body or parameters required
Service Response: A JSON API object with the following attributes:
guid: An identifier used for subsequent status requests
location: A URL to which the actual document package payload can be submitted in the next step. The URL is specific to this upload request, and should not be re-used for subsequent uploads. The URL is valid for 900 seconds (15 minutes) from the time of this response. If the location is not used within 15 minutes, the GUID will expire. Once expired, status checks on the GUID will return a status of expired.
Note: If, after you've submitted a document, the status hasn't changed to uploaded before 15 minutes has elapsed, we recommend retrying the upload in order to make sure the document properly reaches our servers. If the upload continues to fail, try encoding the payload as Base64 (See below).
Client Request: PUT to the location URL returned in Step 2.
Request body should be encoded as binary multipart/form-data (base64 also available - see details below), equivalent to that generated by an HTML form submission or using “curl -F…”. The format is described in more detail below.
No apikey authorization header is required for this request, as authorization is embedded in the signed location URL.
Service Response: The HTTP status indicates whether the upload was successful.
Additionally, the response includes an ETag header containing an MD5 hash of the submitted payload. This can be compared to the submitted payload to ensure data integrity of the upload.
Status caching
Due to current system limitations, data for the /uploads/report endpoint is cached for one hour.
A request to the /uploads/{id} endpoint will return a real-time status for that GUID, and update its status in /uploads/report.
The updated_at field indicates the last time the status for a given GUID was updated.
Optional Base64 encoding
Base64 is an encoding scheme that converts binary data into text format, so that encoded textual data can be easily transported over networks uncorrupted and without data loss.
Base64 can be used to encode binary multipart/form-data it in its entirety. Note that the whole payload must be encoded, not individual parts/attachments.
After encoding your payload, you'll be required to preface your base64 string with data:multipart/form-data;base64, in order to allow our system to distinguish the file type. Your final string payload would look something like data:multipart/form-data;base64,(encryption string)== and close with the standard == marker. Note that the multipart boundaries i.e. -----WebKitFormBoundaryVfOwzCyvug0JmWYo and ending ------WebKitFormBoundaryVfOwzCyvug0JmWYo- must also be included.
Consumer onboarding process
When you're ready to move to production, request a production API key.

This REST-API enables you to query for private transport sharing offers provided by companies and cities in Germany, Netherland and Austria.
You can search for informations about the rental stations (points or areas) where you can find the rentals by utilizing the /areas/ ressource.
With the help of the proximity search in the /bookingproposals/ URI you can request the availabilities of the rentalobjects for spontaneous or planed usage in the future.
Feel free to browse through data by setting the parameter 'providernetwork' to the value:
1: Search for car sharing offers provided by the Flinkster platform (http://www.flinkster.de)
2: Finding bike rental offers from Call a Bike (http://www.callabike.de)
You can find more details in the documentation section (Unfortunately only available in german language).
Have lots of fun and we are lucky to take notice of your products or getting your feedback.

You can use the CORE API to access the
resources harvested and enriched by CORE. If you encounter any problems with the API, please report them to us.
Overview
The API is organised by resource type. The resources are articles,
journals and repositories and are represented using JSON data format. Furthermore,
each resource has a list of methods. The API also provides two global methods for accessing all resources at once.
Response format
Response for each query contains two fields: status and data.
In case of an error status, the data field is empty. The data field contains a single object
in case the request is for a specific identifier (e.g. CORE ID, CORE repository ID, etc.), or
contains a list of objects, for example for search queries. In case of batch requests, the response
is an array of objects, each of which contains its own status and data fields.
For search queries the response contains an additional field totalHits, which is the
total number of items which match the search criteria.
Search query syntax
Complex search queries can be used in all of the API search methods.
The query can be a simple string or it can be built using terms and operators described in Elasticsearch
documentation.
The usable field names are title, description, fullText,
authors, publisher, repositories.id, repositories.name,
doi, oai, identifiers (which is a list of article identifiers including OAI, URL, etc.), language.name
and year. Some example queries:
title:psychology and language.name:English
repositories.id:86 AND year:2014
identifiers:"oai:aura.abdn.ac.uk:2164/3837" OR identifiers:"oai:aura.abdn.ac.uk:2164/3843"
doi:"10.1186/1471-2458-6-309"
Retrieving the latest Articles
You can retrieve the harvested items since specific dates using the following queries:
repositoryDocument.metadataUpdated:>2017-02-10
repositoryDocument.metadataUpdated:>2017-03-01 AND repositoryDocument.metadataUpdated:
Sort order
For search queries, the results are ordered by relevance score. For batch
requests, the results are retrieved in the order of the requests.
Parameters
The API methods allow different parameters to be passed. Additionally, there is an API key parameter which is common to all API methods. For all API methods
the API key can be provided either as a query parameter or in the request header. If the API key
is not provided, the API will return HTTP 401 error. You can register for an API key here.
API methods

A router of public health data from multiple senders and receivers

A RESTful webservice to request a railway journey - FREE plan with restricted access (max. 10 requests per minute). Please ignore the message in the API Console about the access token.
Register to use an less restricted version, which requires an access token.

A simple and elegant way to explore cancer data

Driving License (DL) and Vehicle Registration Certificate (RC) of the State, as available on Parivahan Sewa (http://parivahan.co.in/) of Ministry of Road Transport and Highways, are available on DigiLocker. Citizens can pull these documents into their DigiLocker accounts.

Free API documentation to get Real time corona virus stats

This REST-API enables you to query information about travel centers in Germany.

Driving License (DL) and Vehicle Registration Certificate (RC) of the State, as available on Parivahan Sewa (http://parivahan.co.in/) of Ministry of Road Transport and Highways, are available on DigiLocker. Citizens can pull these documents into their DigiLocker accounts.

Driving License (DL) and Vehicle Registration Certificate (RC) of the State, as available on Parivahan Sewa (http://parivahan.co.in/) of Ministry of Road Transport and Highways, are available on DigiLocker. Citizens can pull these documents into their DigiLocker accounts.

Enforcement and Compliance History Online (ECHO) is a tool developed and maintained by EPA's Office of Enforcement and Compliance Assurance for public use. ECHO provides integrated compliance and enforcement information for over 1 million regulated facilities nationwide.
ECHO Rest Services provide multiple service endpoints, each with specific capabilities, to search and retrieve data on facilities regulated as Clean Air Act (CAA) stationary sources, Clean Water Act (CWA) dischargers, Resource Conservation and Recovery Act (RCRA) hazardous waste generators/handlers, and Safe Drinking Water Act (SDWA) public water systems. Data of interest from other EPA sources, such as the Toxics Release Inventory, is also supplied for context.
\
The getfacilities, getmap, getqid, and getdownload end points are meant to be used together, while the enhanced getfacilityinfo end point is self contained.
The getfacilityinfo end point returns either an array of state, county or zip clusters with summary statistics per cluster or an array of facilities.
\
The recommended use scenario for getfacilities, getqid, getmap, and getdownoad is:
\
1) Use getfacilities to validate passed query parameters, obtain summary statistics and to obtain a queryid (QID). QIDs are time sensitive and will be valid for approximately 30 minutes.
2) Use get_qid, with the returned QID, to paginate through arrays of facility results.
3) Use get_map, with the returned QID, to zoom in/out and pan on the clustered and individual facility coordinates that meet the QID query criteria.
4) Use get_download, with the returned QID, to generate a Comma Separated Value (CSV) file of facility information that meets the QID query criteria.
\
\
Use the qcolumns parameter to customize your search results. Use the Metadata service endpoint for a list of available output objects, their Column Ids, and their definitions to help you build your customized output.
\
Additional ECHO Resources: Web Services, About ECHO's Data, Data Downloads