Thank you for your interest in being included in DesignFast™
This information outlines the preferred method for data ingestion.
WTWH can handle both RESTful and SOAP web services, REST being preferred. If you have an API that you would like WTWH to integrate with DesignFast.com, please provide either a documentation page or a document with the following topics covered:
- What is the http method used for calling your endpoint(s)
- What are the available endpoints to query for data
- What are the headers that are needed for successful request
- What body parameters should be supplied
- Is the request parameters specified in the body of the request or in the url
- What is your preferred authentication mechanism? If we receive an access token, what is your security practice for changing out the token? [ NOTE: At this time, WTWH is not supporting OAuth2.0, as there is no need for identity management.]
- Are there any rate limits?
- Do you paginate? If so, what is your preferred method of pagination? Is your offset zero-based? WTWH’s preferred pagination method would consist of setting an ***offset*** and ***limit***, where the limit set is the amount of parts / request and offset is the partition or “page” in the index.
- Please specify what would occur if WTWH exceeds your offset and limit request. An example would be having duplicate data, an error message, an empty list, etc…
- What is the response data structure and subsequent types? This isn’t dire as we can figure it out, but would be helpful in advance.
- If your API returns certain status codes that have unique meanings, please supply them.
- If you return an error data structure, what is the breakdown?
- When requesting data, do you have any versioning system WTWH should keep in mind? WTWH wants to supply your customers with the latest and greatest data from your index. If you do, how does WTWH override any caching on your end to request the latest part version?
WTWH is also interested in knowing how you manage your API Development & Release Cycles:
- How do you handle migrating to a new version of your API, do you deprecate your old endpoints in a strict time frame?
- What is your preferred method of letting users know there is an update?
For flat files, csv files are preferred in UTF-8 encoding. The table below is a guideline for part data. Flat files can be either sent directly to us via email, dropboxed in our specific folder, or if you have a specific location for your flat file, we can pull the file based on a time interval you’d like to set (e.g., you store it on a server at /parts/myFlatFile.csv and we will make a request to that directory and pull all flat files over rsync / SFTP / or a similar utility. On each new pull, we will overwrite our previous data stored. If you would like us to append the new data to the flat file, rather than overwriting, please let us know in advance.
Part Number/Name | Part Pricing | Part Package Sizes | Part Available | Distributor Name | Manufacturer Name | Manufacturer Part Number | Part Purchase Url | Image Url | Country Code | Datasheet Url | Quantity Available | Minimum Order Quantity
If none of the other data sources are of interest to you, WTWH can open up an endpoint that you could post data too. Just pass your DesignFast specific endpoint a JSON/XML object and WTWH can ingest the data. You’ll have to let WTWH know beforehand on the structure and type of data to be ingested as well as any metadata that should be displayed in regards to your parts listed.
WTWH engineers will give you a token that you’ll include in your http request headers for authentication. The basic data structure standardization to follow is: any company information meta place in the first block, and any parts and their metadata place within the parts array. The example below is the standard data structure.
Please contact us using the form for any questions or requests.