Mock sample for your project: Bharti AXA General Insurance Company Ltd. API
Integrate with "Bharti AXA General Insurance Company Ltd. API" from apisetu.gov.in in no time with Mockoon's ready to use mock sample
Bharti AXA General Insurance Company Ltd.
apisetu.gov.in
Version: 3.0.0
Speed up your application development by using "Bharti AXA General Insurance Company Ltd. API" ready-to-use mock sample. Mocking this API will help you accelerate your development lifecycles and allow you to stop relying on an external API to get the job done. No more API keys to provision, accesses to configure or unplanned downtime, just work.
Enhance your development infrastructure by mocking third party APIs during integrating testing.
Description
APIs provided by Bharti AXA General Insurance Company Ltd..
Other APIs by apisetu.gov.in
Mizoram State Board of School education
apisetu.gov.in
Mizoram Board of School Education, Mizoram (http://www.mbse.edu.in) has made available 2018 Class X and class XII marksheets and passing certificates in DigiLocker, which can be pulled by students into their accounts.
Transport Department, Bihar
apisetu.gov.in
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.
Transport Department, Punjab
apisetu.gov.in
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.
Assam State Board of Secondary Education, Assam
apisetu.gov.in
Board of Secondary Education, Assam (https://sebaonline.org/) has made available 2018 Class X results in DigiLocker, which can be pulled by students into their accounts.
eService (eDistrict), Arunachal Pradesh
apisetu.gov.in
eService (eDistrict), Arunachal Pradesh (http://eservice.arunachal.gov.in/) is the online service delivery portal for Arunachal Pradesh State Govt. Certain documents issued by it (e.g. Income, Caste, Domicile, Dependency, SC/ST ,Character, Residence Certificates etc) are made available in citizens' DigiLocker accounts.
Transport Department, Sikkim
apisetu.gov.in
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.
Motor Vehicle Department, Odisha
apisetu.gov.in
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.
SBI General Insurance Company Ltd
apisetu.gov.in
Insurance Policies such as Car, Two Wheeler, Commercial Vehicle, Health and Travel issued by SBI General (https://www.sbigeneral.in) are now available for Customers to be fetched into their DigiLocker accounts
Gujarat Vidyapith, Ahmedabad
apisetu.gov.in
Gujarat Vidyapith, Ahmedabad (http://www.gujaratvidyapith.org/) is issuing Degree certificates through DigiLocker. These can be pulled by students into their DigiLocker accounts. Currently, data for the year 2019 is made available by Gujarat Vidyapith.
Ministry of Petroleum and Natural Gas(BPCL)
apisetu.gov.in
eSubscription Voucher for LPG connections provided by BPCL (https://bharatpetroleum.com/) are made available to citizens in their DigiLocker accounts.
Ministry of Petroleum and Natural Gas (IOCL)
apisetu.gov.in
eSubscription Voucher for LPG connections provided by IOCL (https://www.iocl.com/) are made available to citizens in their DigiLocker accounts.
State Transport Department, Telangana
apisetu.gov.in
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.
Other APIs in the same category
COVID19 Stats
corona-virus-stats.herokuapp.com
Free API documentation to get Real time corona virus stats
FRC Events
firstinspires.org
Overview
FIRST /FMS FRC Events API is a service to return relevant information about the FIRST Robotics Competition (FRC). Information is made available from events operating around the world.
For FRC, information is made available by the Field Management System (FMS) server operating at each event site. The FMS will attempt to sync all data from the event to "the cloud" as long as internet is available at the venue. If internet is unavailable, or "goes down" during the event, the FMS will automatically sync all data from the time the system was offline as soon as the connection is restored. The API will provide data as soon as it has synced, and we do not add any artificial delays. If you are receiving "stale" data, it may be because of connectivity problems at the venue. We recommend you try again later, and post on the FIRST FMS TeamForge site if the problem persists. (Note: FMS does not sync while a match is running, so data that has to do with a particular match should become available once the score has been revealed to the audience at the event.)
Migration and Program Notes:
Pay close attention to the addresses for calling the various endpoints- as well as the notes regarding endpoints with multiple possible responses (i.e. score details and rankings).
Documentation Notes
All times are listed in the local time to the event venue. HTTP-date values will show their timezone.
If you specify a parameter, but no value for that parameter, it will be ignored. For example, if you request URL?teamNumber= the teamNumber parameter would be ignored.
We will continue to support the current version of the API plus one version older. Old APIs are depricated once a version "two times newer" is available, at minimum 6 months. For example, version 2.0 and 1.0 are supported right now, but 1.0 will not be supported once 2.1 (or 3.0) is available. Versions may also be retired earlier with prior notice here in the documentation.
The full host address of the API is needed in all calls. The version number is required in each call in order to ensure your requests are made (and responses are returned) in the formats you anticipate. The version number for this documentation is found on the top of the page, in the title. If you call this version number, the API responses will match the formats listed below.
All of the APIs are capable of accepting the Accept HTTP header with either application/xml or application/json based on the desired return type. Any API call that results in an HTTP Status Code other than 200 (OK) will only be shown here as an application/json response to save space, but the content is the same regardless of the request type. All response will have a Content-Length and Date response header, but those are not shown in the documentaiton.
For all APIs that accept a query string in addition to the URI base, the order of parameters do not matter, but the name shown in the documentation must match exactly, as does the associated value format as described in details.
For response codes that are not HTTP 200 (OK), the documentation will show a body message that represents a possible response value. While the "title" of the HTTP Status Code will match those shown in the response codes documentation section exactly, the body of the response will be a more detailed explanation of why that status code is being returned and may not always be exactly as shown in the examples.
None of the APIs will show possible return here in the documentation of HTTP 401 (Unauthorized), but that code applies to all APIs as a possible response if the request is made without a valid token.
Last-Modified, FMS-OnlyModifiedSince, and If-Modified-Since Headers
The FRC Events API utilizes the Last-Modified and If-Modified-Since Headers to communicate with consumers regarding the age of the data they are requesting. With a couple of exceptions, all calls will return a Last-Modified Header set with the time at which the data at that endpoint was last modified. The Header will always be set in the HTTP-date format, as described in the HTTP Protocol. There are two exceptions: the Last-Modified Header is not set if the endpoint returns no results (such as a request for a schedule with no matches) and will also not be set if the request was an HTTP DELETE.
Consumers should keep track of the Last-Modified Header, and return it on subsequent calls to the same endpoint as the If-Modified-Since. The server will recognize this request, and will only return a result if the data has been modified since the last request. If no changes have been made, an HTTP 304 will be returned. If data has been modified, ALL data on that call will be returned (for "only modified" data, see below).
The FRC Events API also allows a custom header used to filter the return data to a specific subset. This is done by specifying a FMS-OnlyModifiedSince header with each call. As with the If-Modified-Since header, consumers should keep track of the Last-Modified Header, and return it on subsequent calls to the same endpoint as the FMS-OnlyModifiedSince Header. The server will recognize this request, and will only return a result if the data has been modified since the last request, and, if returned, the data will only be those portions modified since the included date. If no changes, have been made, an HTTP 304 will be returned. Using this method, the server and consumer save processing time by only receiving modified data that is in need of update on the consumer side.
If the Headers are improperly passed (such as the wrong Day of Week for the matching date, or a date in the future), the endpoint will simply ignore the Header and return all results. If both headers are specified, the request will be denied.
Response Codes
The FRC Events API HTTP Status Codes correspond with the common codes, but occasionally with different "titles". The "title" used by the API is shown next to each of the below possible response HTTP Status Codes. Throughout the documentation, Apiary may automatically show the common "title" in example returns (like "Not Found" for 404) but on the production server, the "title" will instead match those listed below.
HTTP 200 - "OK"
The request has succeeded. An entity corresponding to the requested resource is sent in the response. This will be returned as the HTTP Status Code for all request that succeed, even if the body is empty (such as an event that has no rankings, but with a valid season and event code were used)
HTTP 304 - "Not Modified"
When utilizing a Header that allows filtered data returns, such as If-Modified-Since, this response indicates that no data meets the request.
HTTP 400 - "Invalid Season Requested"/"Malformed Parameter Format In Request"/"Missing Parameter In Request"/"Invalid API Version Requested":
The request could not be understood by the server due to malformed syntax. The client SHOULD NOT repeat the request without modifications. Specifically for this API, a 400 response indicates that the requested URI matches with a valid API, but one or more required parameter was malformed or invalid. Examples include an event code that is too short or team number that contains a letter.
HTTP 401 - "Unauthorized"
All requests against the API require authentication via a valid user token. Failing to provide one, or providing an invalid one, will warrant a 401 response. The client MAY repeat the request with a suitable Authorization header field.
HTTP 404 - "Invalid Event Requested"
Even though the 404 code usually indicates any not found status, a 404 will only be issued in this API when an event cannot be found for the requested season and event code. If the request didn't match a valid API or there were malformed parameters, the response would not receive a 404 but rather a 400 or 501. If this HTTP code is received, the season was a valid season and the event code matched the acceptable style of an event code, but there were no records of an event matching the combination of that season and event code. For example, HTTP 404 would be issued when the event had a different code in the requested season (the codes can change year to year based on event location).
HTTP 500 - "Internal Server Error"
The server encountered an unexpected condition which prevented it from fulfilling the request. This is a code sent directly by the server, and has no special alternate definition specific to this API.
HTTP 501 - "Request Did Not Match Any Current API Pattern"
The server does not support the functionality required to fulfill the request. Specifically, the request pattern did not match any of the possible APIs, and thus processing was discontinued. This code is also issued when too many optional parameters were included in a single request and fulfilling it would make the result confusing or misleading. Each API will specify which parameters or combination of parameters can be used at the same time.
HTTP 503 - "Service Unavailable"
The server is currently unable to handle the request due to a temporary overloading or maintenance of the server. The implication is that this is a temporary condition which will be alleviated after some delay. If known, the length of the delay MAY be indicated in a Retry-After header. This code will not always appear, sometimes the server may outright refuse the connection instead. This is a code sent directly by the server, and has no special alternate definition specific to this API.
See the notes at the top of this documentation for important information about HTTP Status Codes.
Authorization
In order to make calls against the FRC Events API, you must include an HTTP Header called Authorization with the value set as specified below. If a request is made without this header, processing stops and an HTTP 401 is issued. All Authorization headers follow the same format:
Authorization: Basic 000000000000000000000000000000000000000000000000000000000000
Where the Zeros are replaced by your Token. The Token can be formed by taking your username and your AuthorizationKey and adding a colon. For example, if your username is sampleuser and your AuthorizationKey is 7eaa6338-a097-4221-ac04-b6120fcc4d49 you would have this string:
sampleuser:7eaa6338-a097-4221-ac04-b6120fcc4d49
This string must then be encoded using Base64 Encoded to form the Token, which will be the same length as the example above, but include letters and numbers. For our example, we would have:
c2FtcGxldXNlcjo3ZWFhNjMzOC1hMDk3LTQyMjEtYWMwNC1iNjEyMGZjYzRkNDk=
NOTICE : Publicly distributing an application, code snippet, etc, that has your username and token in it, encoded or not, WILL result in your token being blocked from the API. Each user should apply for their own token.
If you wish to acquire a token for your development, you may do so by requesting a token through our automated system on this website.
AUTOMATED REMOVAL : If you do not activate your account within 72 hours of making your request for a token, or if you do not make at least one API request every twelve (12) months, your account/token will be marked as disabled for inactivity and subject to being deleted. (This policy does not apply to accounts with special operating agreements with FIRST)
HTTP401 and Authorization
Each Token can be individually enabled and disabled by FIRST. As such, a normally valid combination of username and AuthorizationToken could still be rejected. The possible return messages you may see in these instances are:
Incorrect Token (You supplied an AuthorizationToken, but it wasn't correct)
Account Disabled, Contact Support (You have been disabled for excessive traffic or abuse. Contact support)
Username Not Found (A username was found, but didn't match any on file)
Unable To Determine Authorization Token (The format of the Authorization header was incorrect)
FIRST /FMS FRC Events API is a service to return relevant information about the FIRST Robotics Competition (FRC). Information is made available from events operating around the world.
For FRC, information is made available by the Field Management System (FMS) server operating at each event site. The FMS will attempt to sync all data from the event to "the cloud" as long as internet is available at the venue. If internet is unavailable, or "goes down" during the event, the FMS will automatically sync all data from the time the system was offline as soon as the connection is restored. The API will provide data as soon as it has synced, and we do not add any artificial delays. If you are receiving "stale" data, it may be because of connectivity problems at the venue. We recommend you try again later, and post on the FIRST FMS TeamForge site if the problem persists. (Note: FMS does not sync while a match is running, so data that has to do with a particular match should become available once the score has been revealed to the audience at the event.)
Migration and Program Notes:
Pay close attention to the addresses for calling the various endpoints- as well as the notes regarding endpoints with multiple possible responses (i.e. score details and rankings).
Documentation Notes
All times are listed in the local time to the event venue. HTTP-date values will show their timezone.
If you specify a parameter, but no value for that parameter, it will be ignored. For example, if you request URL?teamNumber= the teamNumber parameter would be ignored.
We will continue to support the current version of the API plus one version older. Old APIs are depricated once a version "two times newer" is available, at minimum 6 months. For example, version 2.0 and 1.0 are supported right now, but 1.0 will not be supported once 2.1 (or 3.0) is available. Versions may also be retired earlier with prior notice here in the documentation.
The full host address of the API is needed in all calls. The version number is required in each call in order to ensure your requests are made (and responses are returned) in the formats you anticipate. The version number for this documentation is found on the top of the page, in the title. If you call this version number, the API responses will match the formats listed below.
All of the APIs are capable of accepting the Accept HTTP header with either application/xml or application/json based on the desired return type. Any API call that results in an HTTP Status Code other than 200 (OK) will only be shown here as an application/json response to save space, but the content is the same regardless of the request type. All response will have a Content-Length and Date response header, but those are not shown in the documentaiton.
For all APIs that accept a query string in addition to the URI base, the order of parameters do not matter, but the name shown in the documentation must match exactly, as does the associated value format as described in details.
For response codes that are not HTTP 200 (OK), the documentation will show a body message that represents a possible response value. While the "title" of the HTTP Status Code will match those shown in the response codes documentation section exactly, the body of the response will be a more detailed explanation of why that status code is being returned and may not always be exactly as shown in the examples.
None of the APIs will show possible return here in the documentation of HTTP 401 (Unauthorized), but that code applies to all APIs as a possible response if the request is made without a valid token.
Last-Modified, FMS-OnlyModifiedSince, and If-Modified-Since Headers
The FRC Events API utilizes the Last-Modified and If-Modified-Since Headers to communicate with consumers regarding the age of the data they are requesting. With a couple of exceptions, all calls will return a Last-Modified Header set with the time at which the data at that endpoint was last modified. The Header will always be set in the HTTP-date format, as described in the HTTP Protocol. There are two exceptions: the Last-Modified Header is not set if the endpoint returns no results (such as a request for a schedule with no matches) and will also not be set if the request was an HTTP DELETE.
Consumers should keep track of the Last-Modified Header, and return it on subsequent calls to the same endpoint as the If-Modified-Since. The server will recognize this request, and will only return a result if the data has been modified since the last request. If no changes have been made, an HTTP 304 will be returned. If data has been modified, ALL data on that call will be returned (for "only modified" data, see below).
The FRC Events API also allows a custom header used to filter the return data to a specific subset. This is done by specifying a FMS-OnlyModifiedSince header with each call. As with the If-Modified-Since header, consumers should keep track of the Last-Modified Header, and return it on subsequent calls to the same endpoint as the FMS-OnlyModifiedSince Header. The server will recognize this request, and will only return a result if the data has been modified since the last request, and, if returned, the data will only be those portions modified since the included date. If no changes, have been made, an HTTP 304 will be returned. Using this method, the server and consumer save processing time by only receiving modified data that is in need of update on the consumer side.
If the Headers are improperly passed (such as the wrong Day of Week for the matching date, or a date in the future), the endpoint will simply ignore the Header and return all results. If both headers are specified, the request will be denied.
Response Codes
The FRC Events API HTTP Status Codes correspond with the common codes, but occasionally with different "titles". The "title" used by the API is shown next to each of the below possible response HTTP Status Codes. Throughout the documentation, Apiary may automatically show the common "title" in example returns (like "Not Found" for 404) but on the production server, the "title" will instead match those listed below.
HTTP 200 - "OK"
The request has succeeded. An entity corresponding to the requested resource is sent in the response. This will be returned as the HTTP Status Code for all request that succeed, even if the body is empty (such as an event that has no rankings, but with a valid season and event code were used)
HTTP 304 - "Not Modified"
When utilizing a Header that allows filtered data returns, such as If-Modified-Since, this response indicates that no data meets the request.
HTTP 400 - "Invalid Season Requested"/"Malformed Parameter Format In Request"/"Missing Parameter In Request"/"Invalid API Version Requested":
The request could not be understood by the server due to malformed syntax. The client SHOULD NOT repeat the request without modifications. Specifically for this API, a 400 response indicates that the requested URI matches with a valid API, but one or more required parameter was malformed or invalid. Examples include an event code that is too short or team number that contains a letter.
HTTP 401 - "Unauthorized"
All requests against the API require authentication via a valid user token. Failing to provide one, or providing an invalid one, will warrant a 401 response. The client MAY repeat the request with a suitable Authorization header field.
HTTP 404 - "Invalid Event Requested"
Even though the 404 code usually indicates any not found status, a 404 will only be issued in this API when an event cannot be found for the requested season and event code. If the request didn't match a valid API or there were malformed parameters, the response would not receive a 404 but rather a 400 or 501. If this HTTP code is received, the season was a valid season and the event code matched the acceptable style of an event code, but there were no records of an event matching the combination of that season and event code. For example, HTTP 404 would be issued when the event had a different code in the requested season (the codes can change year to year based on event location).
HTTP 500 - "Internal Server Error"
The server encountered an unexpected condition which prevented it from fulfilling the request. This is a code sent directly by the server, and has no special alternate definition specific to this API.
HTTP 501 - "Request Did Not Match Any Current API Pattern"
The server does not support the functionality required to fulfill the request. Specifically, the request pattern did not match any of the possible APIs, and thus processing was discontinued. This code is also issued when too many optional parameters were included in a single request and fulfilling it would make the result confusing or misleading. Each API will specify which parameters or combination of parameters can be used at the same time.
HTTP 503 - "Service Unavailable"
The server is currently unable to handle the request due to a temporary overloading or maintenance of the server. The implication is that this is a temporary condition which will be alleviated after some delay. If known, the length of the delay MAY be indicated in a Retry-After header. This code will not always appear, sometimes the server may outright refuse the connection instead. This is a code sent directly by the server, and has no special alternate definition specific to this API.
See the notes at the top of this documentation for important information about HTTP Status Codes.
Authorization
In order to make calls against the FRC Events API, you must include an HTTP Header called Authorization with the value set as specified below. If a request is made without this header, processing stops and an HTTP 401 is issued. All Authorization headers follow the same format:
Authorization: Basic 000000000000000000000000000000000000000000000000000000000000
Where the Zeros are replaced by your Token. The Token can be formed by taking your username and your AuthorizationKey and adding a colon. For example, if your username is sampleuser and your AuthorizationKey is 7eaa6338-a097-4221-ac04-b6120fcc4d49 you would have this string:
sampleuser:7eaa6338-a097-4221-ac04-b6120fcc4d49
This string must then be encoded using Base64 Encoded to form the Token, which will be the same length as the example above, but include letters and numbers. For our example, we would have:
c2FtcGxldXNlcjo3ZWFhNjMzOC1hMDk3LTQyMjEtYWMwNC1iNjEyMGZjYzRkNDk=
NOTICE : Publicly distributing an application, code snippet, etc, that has your username and token in it, encoded or not, WILL result in your token being blocked from the API. Each user should apply for their own token.
If you wish to acquire a token for your development, you may do so by requesting a token through our automated system on this website.
AUTOMATED REMOVAL : If you do not activate your account within 72 hours of making your request for a token, or if you do not make at least one API request every twelve (12) months, your account/token will be marked as disabled for inactivity and subject to being deleted. (This policy does not apply to accounts with special operating agreements with FIRST)
HTTP401 and Authorization
Each Token can be individually enabled and disabled by FIRST. As such, a normally valid combination of username and AuthorizationToken could still be rejected. The possible return messages you may see in these instances are:
Incorrect Token (You supplied an AuthorizationToken, but it wasn't correct)
Account Disabled, Contact Support (You have been disabled for excessive traffic or abuse. Contact support)
Username Not Found (A username was found, but didn't match any on file)
Unable To Determine Authorization Token (The format of the Authorization header was incorrect)
Authorized Partner API Specification
digitallocker.gov.in
To access files in user’s DigiLocker account from your application, you must first obtain user’s authorization.
U.S. EPA Enforcement and Compliance History Online (ECHO) - Clean Water Act (CWA) Rest Services
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.
CWA Rest Services provides multiple service endpoints, each with specific capabilities, to search and retrieve data on facilities regulated under the Clean Water Act (CWA) and managed under the National Pollutant Discharge Elimination System (NPDES) program. The returned results reflect data drawn from EPA's ICIS-NPDES database.
\
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
CWA Rest Services provides multiple service endpoints, each with specific capabilities, to search and retrieve data on facilities regulated under the Clean Water Act (CWA) and managed under the National Pollutant Discharge Elimination System (NPDES) program. The returned results reflect data drawn from EPA's ICIS-NPDES database.
\
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
Groundwater Wells, Aquifers and Registry API
gov.bc.ca
The groundwater wells, aquifers and registry API contains information related to groundwater wells and aquifers as well as a register of qualified well drillers and well pump installers registered to operate in B.C.
Bhagavad Gita API
bhagavadgita.io
Climate FieldView Platform APIs
climate.com
Last Modified: Thu Oct 29 12:30:46 PDT 2020
All endpoints are only accessible via HTTPS.
All API endpoints are located at https://platform.climate.com (e.g.
https://platform.climate.com/v4/fields).
The authorization token endpoint is located at
https://api.climate.com/api/oauth/token.
Troubleshooting
X-Http-Request-Id response header will be returned on every call,
successful or not. If you experience an issue with our api and need
to contact technical support, please supply the value of the X-Http-Request-Id
header along with an approximate time of when the request was made.
Request Limits
When you’re onboarded to Climate’s API platform, your x-api-key is assigned a custom usage plan. Usage plans are unique to each partner and have the following key attributes:
Throttling information
burstLimit: Maximum rate limit over a period ranging from 1 second to a few seconds
rateLimit: A steady-state rate limit
Quota information
Limit: The maximum number of requests that can be made in a given month
When the request rate threshold is exceeded, a 429 response code is returned. Optionally, the Retry-After header may be returned:
Following are examples of rate limit errors:
Rate limit exceeded:
HTTP/1.1 429
Content-Type: application/json
Content-Length: 32
{"message":"Too Many Requests"}
Quota exhausted:
HTTP/1.1 429
Content-Type: application/json
Content-Length: 29
{"message":"Limit Exceeded"}
Pagination
Pagination is performed via headers. Any request which returns a "results"
array may be paginated. The following figure shows how query results are laid out with
X-Limit=4 and no filter applied.
If there are no results, a response code of 304 will be returned.
If the response is the last set of results, a response code of 200 or
206 will be returned.
If there are more results, a response code of 206 will be returned.
If X-Next-Token is provided in the request headers but the token has
expired, a response code of 409 will be returned. This is only applicable
for some endpoints; see specific endpoint documentation below.
X-Limit
The page size can be controlled with the X-Limit header. Valid values are
1-100 and defaults to 100.
X-Next-Token
If the results are paginated, a response header of X-Next-Token will be
returned. Use the associated value in the subsequent request (via the X-Next-Token
request header) to retrieve the next page. The following sequence diagram shows how to
use X-Next-Token to fetch all the records.
Chunked Uploads
Uploads larger than 5MiB (5242880 bytes) must be done in 5MiB chunks
(with the exception of the final chunk). Each chunk request MUST contain a
Content-Range header specifying the portion of the upload, and a Content-Type
header specifying binary content type (application/octet-stream). Range
uploads must be contiguous. The maximum upload size is capped at 500MiB (524288000 bytes).
Chunked Downloads
Downloads larger than 5MiB (5242880 bytes) must be done in 1-5MiB
chunks (with the exception of the final chunk, which may be less than 1MiB).
Each chunk request MUST contain a Range header specifying the requested portion of the download,
and an Accept header specifying binary and json content types (application/octet-stream,application/json)
or all content types (/).
Drivers
If you need drivers to process agronomic data, download the ADAPT plugin below. We only support the plugin in the Windows environment, minimum is Windows 7 SP1.
For asPlanted, asHarvested and asApplied data:
ADAPT Plugin
Release notes can be found here.
Download and use of the ADAPT plugin means that you agree to the EULA for use of the ADAPT plugin.
Please review the EULA (last updated on June 6th, 2019) before download and use of the ADAPT plugin.
For more information, please refer to:
ADAPT Resources
ADAPT Overview
ADAPT FAQ
ADAPT Videos
Sample Test Data
Sample agronomic data:
asPlanted and asHarvested data
asApplied data set 1
asApplied data set 2
To upload the sample data to your account, please follow the instructions in this link.
Sample soil data:
Sample soil data
All endpoints are only accessible via HTTPS.
All API endpoints are located at https://platform.climate.com (e.g.
https://platform.climate.com/v4/fields).
The authorization token endpoint is located at
https://api.climate.com/api/oauth/token.
Troubleshooting
X-Http-Request-Id response header will be returned on every call,
successful or not. If you experience an issue with our api and need
to contact technical support, please supply the value of the X-Http-Request-Id
header along with an approximate time of when the request was made.
Request Limits
When you’re onboarded to Climate’s API platform, your x-api-key is assigned a custom usage plan. Usage plans are unique to each partner and have the following key attributes:
Throttling information
burstLimit: Maximum rate limit over a period ranging from 1 second to a few seconds
rateLimit: A steady-state rate limit
Quota information
Limit: The maximum number of requests that can be made in a given month
When the request rate threshold is exceeded, a 429 response code is returned. Optionally, the Retry-After header may be returned:
Following are examples of rate limit errors:
Rate limit exceeded:
HTTP/1.1 429
Content-Type: application/json
Content-Length: 32
{"message":"Too Many Requests"}
Quota exhausted:
HTTP/1.1 429
Content-Type: application/json
Content-Length: 29
{"message":"Limit Exceeded"}
Pagination
Pagination is performed via headers. Any request which returns a "results"
array may be paginated. The following figure shows how query results are laid out with
X-Limit=4 and no filter applied.
If there are no results, a response code of 304 will be returned.
If the response is the last set of results, a response code of 200 or
206 will be returned.
If there are more results, a response code of 206 will be returned.
If X-Next-Token is provided in the request headers but the token has
expired, a response code of 409 will be returned. This is only applicable
for some endpoints; see specific endpoint documentation below.
X-Limit
The page size can be controlled with the X-Limit header. Valid values are
1-100 and defaults to 100.
X-Next-Token
If the results are paginated, a response header of X-Next-Token will be
returned. Use the associated value in the subsequent request (via the X-Next-Token
request header) to retrieve the next page. The following sequence diagram shows how to
use X-Next-Token to fetch all the records.
Chunked Uploads
Uploads larger than 5MiB (5242880 bytes) must be done in 5MiB chunks
(with the exception of the final chunk). Each chunk request MUST contain a
Content-Range header specifying the portion of the upload, and a Content-Type
header specifying binary content type (application/octet-stream). Range
uploads must be contiguous. The maximum upload size is capped at 500MiB (524288000 bytes).
Chunked Downloads
Downloads larger than 5MiB (5242880 bytes) must be done in 1-5MiB
chunks (with the exception of the final chunk, which may be less than 1MiB).
Each chunk request MUST contain a Range header specifying the requested portion of the download,
and an Accept header specifying binary and json content types (application/octet-stream,application/json)
or all content types (/).
Drivers
If you need drivers to process agronomic data, download the ADAPT plugin below. We only support the plugin in the Windows environment, minimum is Windows 7 SP1.
For asPlanted, asHarvested and asApplied data:
ADAPT Plugin
Release notes can be found here.
Download and use of the ADAPT plugin means that you agree to the EULA for use of the ADAPT plugin.
Please review the EULA (last updated on June 6th, 2019) before download and use of the ADAPT plugin.
For more information, please refer to:
ADAPT Resources
ADAPT Overview
ADAPT FAQ
ADAPT Videos
Sample Test Data
Sample agronomic data:
asPlanted and asHarvested data
asApplied data set 1
asApplied data set 2
To upload the sample data to your account, please follow the instructions in this link.
Sample soil data:
Sample soil data
Veer Surendra Sai University Of Technology
apisetu.gov.in
Veer Surendra Sai University Of Technology, Odisha (http://vssut.ac.in) is issuing Degree certificates through DigiLocker. These can be pulled by students into their DigiLocker accounts. Currently, data for the year's 2014-2019 is made available by Veer Surendra Sai University Of Technology.
Canada Holidays API
This API that lists all 28 public holidays for all 13 provinces and territories in Canada, including federal holidays.
COVID-19 data API
covid19-api.com
U.S. EPA Enforcement and Compliance History Online (ECHO) - Clean Air Act
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.
Air Rest Services provides multiple service endpoints, each with specific capabilities, to search and retrieve data on facilities regulated under the Clean Air Act (CAA). The returned results reflect data drawn from EPA's ICIS-Air database.
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
Air Rest Services provides multiple service endpoints, each with specific capabilities, to search and retrieve data on facilities regulated under the Clean Air Act (CAA). The returned results reflect data drawn from EPA's ICIS-Air database.
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