Introduction

Scientist’s Application Programming Interface (API) gives application developers programmatic access to the Scientist.com marketplace platform. Developers servicing suppliers and client organizations can use the API to add value to marketplace. Some example applications are:

• CRM Integration: Tight integration of supplier CRM with marketplace requests
• Purchasing Integration: Tight integration of client purchasing system
• Decision Support: Supplier provides estimator for client request in real-time
• Decision Support: Supplier provides context aware resources and reference material to support client request

Overview

The API provides facilities for free-text and faceted search of the major entities stored in the marketplace. Unless otherwise noted, GET requests with no parameters to the endpoints returns the the first page of results and a facets object describing the features available for query. Developers can use the information returned by the first request to create a picklist or otherwise issue another request with more specific criteria.

Most index endpoints accept per_page= and page= query string parameters. Use the response from the initial query to iterate over pages of responses. See URL Query Parameters for information on free-text and facet searching for endpoints that support that feature.

Included in this API is a powerful Webhooks callback mechanism allowing applictions to register callbacks to private applications whereby events occuring on the marketplace are delivered to developer applications. In this way third party applications maintain synchronicity with activities on the Scientist.com marketplace.

API access is granted through a user account enabled with the appropriate developer permissions on Scientist.com.

To request an account or the developer feature, please email professional.services@scientist.com.

Once your access has been reviewed and approved, you will gain access to generate API tokens to be used in authenticating into the application.

To use the API you first authenticate using either token or OAuth2.

Getting Started

Organization

Organization of this site is alphabetical.

The endpoint references the Terminology for definitions of terms used throughout the platform. Terminology is cross-linked throughout the site.

A number of endpoints provide facet query facilities the function identically though the facet names are obviously different depending on the objects being searched. Refer to the URL Query Paramaters for details on how to format URL query strings.

If you link to a location in the site, use the browser back button to return.

Endpoint documentation

Each endpoint is described in the main panel of the site. To the right there are request and response tabs. The former showing the curl style command you would use to contact the endpoint. Select the response tab to see and example of the server response.

Location

The Scientist.com API is accessible at whatever website you use to access the marketplace.

• https://app.scientist.com/api/v2/resource
• https://custom.scientist.com/api/v2/resource
• https://backoffice.scientist.com/api/v2/resource

Authentication

API access is granted through a user account enabled with the appropriate developer permissions on Scientist.com.

To request an account or the developer feature, please email professional.services@scientist.com.

Once your access has been reviewed and approved, you will gain access to generate API tokens to be used in authenticating into the application.

To authenticate an application developers first "create" the application using their Scientist.com account as follows:

1. Log in to your Scientist account
2. Go to Developer > Applications > New Application
3. Fill in the fields as appropriate and click Create
4. If you intend to use Oauth2authentication then you must supply a callback URL where the Oauth2 Server can issue a CODE to be given as argument to the Token URL before an ACCESS_TOKEN is issued.

Token Authentication

GET https://app.scientist.com/api/resource.json?access_token=ACESS_TOKEN

The simplest means to use the API is to embed the ACCESS_TOKEN as a URL query string.

curl --header "Authorization: Bearer ACCESS_TOKEN" https://app.scientist.com/api/resource.json

Alternatively submit the token as a header property as follows: "Authorization: Bearer ACCESS_TOKEN" where the provided token is substituted for the ACCESS_TOKEN in the header string.

Oauth2

The Scientist.com API supports a full Oauth2 workflow. The steps are:

1. Use the CLIENT_ID and CLIENT_SECRET to initiate an authorization session. The Oauth2 server will respond to the callback server with a CODE once the user credentials have been established.
2. Substitute the CODE provided in Step 1 to the Token URL to request an access token.
3. The Token URL responds with an access token to be used in the manner of the Token Authentication described above.

Authorization URL

GET https://app.scientist.com/oauth/authorize?client_id=CLIENT_ID

Request a CODE by substitute the CLIENT_ID provided by the web site into the Authorization URL.

Token URL

GET https://app.scientist.com/oauth/token?grant_type=authorization_code&code=CODE&client_id=CLIENT_SECRET&client_secret=CLIENT_SECRET

Substitute the CLIENT_ID, CLIENT_SECRET provided by the web site, the CODE from the authorization URL response into the Token URL.

Terminology

The Scientist.com platform relies on a specific set of concepts, terms and meanings. Below is a list of some of the major terms and concepts important to API:

Action Item

Action Items are documents that provide a trace back of the events timeline for requests, proposals, purchase orders and other activities on the Scientist.com platform.

By way of example, if a supplier submits an SOW (Statement Of Work), the marketplace expects the next action is the user will accept that sow. The action item for the submitting SOW user is updated to reflect, action_performed: "sow_submitted", and a new action next_action: "accept_sow" get created. The new action includes a generated link to the page where the requesting user can actually accept the SOW. Subsequent action items can trigger webhooks (including email notices and push notifications), as well as populating the digest emails.

Approval

A document describing the approval context and status of a compliance manifest.

Approval documents can be approved, denied, delegated, and cancelled.

Approver

A user authorized on behalf of a client organization to review and approve compliance manifests.

Category

A description of a set of related wares.

Suppliers of goods and services registering on the marketplace select from a list of categories to describe their wares. Applications can use this information to create picklists or otherwise search the marketplace for specific, relevant categories of suppliers.

Compliance Manifest

Approval document associated with requests, proposals, and purchases. Requestors complete manifest questionaires based on the policies for specific marketplaces. Approvers receive notifications from the marketplace alerting them to pending compliance manifest approvals. Approvers can elect to Approve, Deny, Delegate, or Cancel a request for approval.

Dynamic Form

A custom form used to request goods and services, inform compliance, or structure proposals in the case of a provider.

Dynamic List

Dynamic Lists provide a means to support custom lists in the platform. Companies with list of things that they want users to select from during compliance (or whatever step in the system) can use Dynamic Lists to implement these rules.

Event

Any marketplace event. Examples include a submitted request for quotation or proposal, or accepted proposal.

Organization

A client company that uses the marketplace to request, approve, and procure goods and services. By contrast Providers refer to suppliers of goods and survices on the marketplace.

Proposal

A providers response to a Request is a proposal. A proposal is attached to a Quoted Ware which is itself associated with the corresponding Quote Group.

Provider

A supplier or vendor of goods and services.

Provider-Ware

A set of 1 or more wares associated with a provider.

Quote Group

A collection of 1 or more requests for quotation for a specific set of goods and services. Visible to the requesting client organization.

Marketplace "quote groups" refer to the customer view of a request for quote for wares. By contrast, a quoted ware represents the provider view of the similar information.

Quoted Ware

A collection of 1 or more responses or proposals submitted on behalf of a provider in response to a request from a client. Visible to the provider submitting the quote(s).

Marketplace "quoted wares" refer to provider view of a request for goods and services initiated by a client on the system. By contrast, a quote group represents the client view of similar information.

Request

A request for goods and services on the system resulting in a Quote Group

Requestor

A user who initiates a request for goods and services.

Token-User

The user account connected to the authorization token granting access to the API.

User

An authorized user on the system who is a member of either a Provider or client Organization on the marketplace.

Wares

A collection of goods and services available for sale via the marketplace.

Ware-Provider

A set of 1 or more providers associated with a ware.

Webhook

A URL accepting a request and data from the marketplace in response to an event occurring on the marketplace. See Webhooks.

Webhooks

Webhooks provide a way for application developers to register http request callbacks and implement their own business logic for Marketplace Events. Examples of webhook events and associated webhook actions are:

• A client issues a request for quote and a webhook notifies a supplier application.
• A supplier issues a quotation through the marketplace and a webhook notifies the clients internal system of the supplied quotation.
• A client decides to accept a proposal on the marketplace and a webhook synchronizes the event with the clients internal purchasing system.

For a complete list of webhook events, see Marketplace Events

An example JSON POST body:
{
    email: "email",
    subject: "subject string",
    subdomain: "subdomain",
    url: "url",
    quote_group_description_html: "html_description",
    quote_group_description_text: "description",
    compliance_type: "type",
    identifier: "identifier",
    vendor_identifier: "vendor_identifier",
    quote_group_id: "quote_group_id",
    quoted_ware_id: "quoted_ware_id",
    provider_rfi_annotation_status: "status",
    provider_rfi_annotation_badge_type: "badge_type",
    proposal_id: "proposal_id",
    purchase_order_id: "purchase_order_id",
    compliance_manifest_id: "compliance_manifest_id",
    multipage_form_id: "multipage_form_id",
    multipage_form_name: "multipage_form_name",
    multipage_form_expires_on: "multipage_form_expires_on",
    approval_id: "approval_id",
    note_id: "note_id",
    provider_id: "provider_id",
    provider_name: "provider_name",
    title: "title",
    action_performed: "action_performed",
    action_performed_human: "action_performed_human",
    marketplace: "marketplace",
    html_description: "html_description",
    text_description: "text_description",
    body: "string reason for cancelling or other attachments",
    template_name: "email_template",
    attachments: "attached_pdfs"
}

Developers configuring webhooks must implement the corresponding callback server POST request corresponding to url provided to the webhook. The json body supplied with the callback provides the complete context of the triggered event.

The Scientist.com server relies on the host server handling the webhook POST request to authenticate the POST request and to verify the ligitimacy of the webhook. One approach is to use Basic authentication configured on the webhook URL. Another approach is to supply a key and verify it using the params key/value hash provided when instantiating the webhook. To avoid unneccessary privacy exposures, we strongly recommend you host your application using SSL encryption.

Marketplace Events

Marketplace events are used by the notification engine to trigger notifications that certain events are happening which may require their involvement. See Webhook Configuration for details on configuring webhooks.

Webhooks can be registered for specific events or all events See Marketplace Events for details. Once a webhook is registered, whenever an event occurs, the marketplace engine will initiate a POST request to the supplied URL with a payload describing the Quoted Ware in the case of a Provider user, or a Quote Group in the case of a Client user. In addition, the webhook can be configured to deliver known key/values to the callback server which can be used to verify the legitimacy of the callback.

Eligible webhook events depend on the user status on the marketplace for the associated Authorization Code.

V2 API Endpoints

Action Items

GET https://app.scientist.com/api/v2/action_items.json

The endpoint provides paged access to all action items associated with the token-user. Use the standard per_page and page query parameters to control number of results returned with each request. See Paging and Sorting for more details on paging and sorting.

Filter By Webhook Name

GET https://app.scientist.com/api/v2/action_items.json?name=Webhook+Config+Name

It is possible for a webhook configuration to declare notification only on certain events. In that case the requestor can use the URL query string the ?name=Application Name substituting the name of the webhook configuration for Application Name in this example. By specifying the ?name=Application Name query parameter only events related to the named webhook configuration will be returned in the response.

Approvals

GET https://app.scientist.com/api/v2/compliance_manifests/:uuid/approvals.json

Approval documents are children of Compliance Manifests.

Use the compliance_manifests/:uuid/approvals.json endpoint to fetch the approval_refs associated with a compliance manifest document. This endpoint is an alternative to the /compliance_manifest/:uuid.json endpoint returning the same approval_refs without the additional compliance manifest document detail.

Actions available to compliance manifest approvals include: approve, deny, delegate, and undo.

Approve

PUT https://app.scientist.com/api/v2/compliance_manifests/:approvable_uuid/approvals/:uuid/approve.json

  {"approval": 
    {
      "reason": "my reason"
    }
  }

Approve requests by PUT to the approve.json endpoint with the :approvable_uuid for the compliance manifest and the approval document :uuid. Include a json body document with an approval property containing an object with a reason property describing why the request is approved.

Deny

Deny requests by PUT to the deny.json endpoint with the :approvable_uuid for the compliance manifest and the :uuid of the approval document. Include a json body document with an approval property containing an object with a reason property describing why the request is denied.

PUT  https://app.scientist.com/api/v2/compliance_manifests/:approvable_uuid7/approvals/24107c08-d923-44fd-931/:uuid/deny.json

  {"approval": 
    {
      "reason": "my denial reason"
    }
  }

Delegate

PUT  https://app.scientist.com/api/v2/compliance_manifests/:approvable_uuid7/approvals/24107c08-d923-44fd-931/:uuid/delegate.json

{"approval": {"reassign_approval_to": ["ron@scientist.com"]}}

Delegate request approvals to another eligible approver for the current marketplace by PUT to the delegate.json endpoint with the :approvable_uuid for the compliance manifest and :uuid for the approval document. Include a json body document with an approval property containing an object with an reassign_approval_to property containing an array of email strings.

The endpoint will filter any reassigned emails lacking privilege to complete the approval.

Undo

PUT  https://app.scientist.com/api/v2/compliance_manifests/:approvable_uuid7/approvals/24107c08-d923-44fd-931/:uuid/cancel.json

The '/undo.json` endpoint resets an approval to its original state before the approval was either Denied or Approved. As such this endpoint has no effect on an approval in its initial state.

Undo request approvals by PUT to the undo.json endpoint with the :approvable_uuid for the compliance manifest and :uuid for the approval document.

Categories

GET https://app.scientist.com/api/v2/categories.json

The API V2 /categories.json index endpoint produces a flattened array of categories each with 0 or more ancestor-slugs and a connection to the immediate parent category via parent-slug or parent-uuid.

Categories can have multiple sub-categories. There is no physical limit to the category nesting. Each category, regardless of its place in the hierarchy has a unique slug identifier provided in the response object.

Category Tree

GET https://app.scientist.com/api/v2/categories.json?tree=true

The response is an array of top level categories, each with one or more children categories. In turn, each child can have 0 or more children in a hierarchical fashion.

A Specific Category

GET http://app.scientist.com/api/v2/categories/:slug.json

Use the slug to request an individual category record.

Compliance Manifests

GET http://app.scientist.com/api/v2/compliance_manifests.json

This endpoint retrieves all compliance manifests visible to the requestor.

The /compliance_manifests.json endpoint responds with a response json with a the first page of compliance manifest documents. The response includes two json properties compliance_manifest_refs and facets. The former is an array of documents you can use to populate your table. The response property facets contains a structured json of search criteria related to the remaining documents available, based on the current value of the search.

See URL Query Parameters for details on paging, sorting and facet searching.

A Specific Compliance Manifest

GET http://app.scientist.com/api/v2/compliance_manifests/;uuid.json

Use the uuid associated with a specific compliance manifest document to retrieve a detailed json response.

The response json will include details of the associated request or quote_group, additional approval documents approval_refs as well as details for associated proposal and purchase_order objects.

Dynamic Forms

GET https://app.scientist.com/api/v2/dynamic_form/:form_id.json

The API has limited functions in relation to dynamic forms. However, dynamic forms are data-driven therefore the API provides some means for reading dynamic forms data from the database for rendering on mobile devices and for archival purposes.

This endpoint retrieves a specific form by its identifier.

Dynamic Lists

GET https://app.scientist.com/api/v2/dynamic_lists.json

Use Dynamic Lists to align internal systems with the marketplace.

A Specific Dynamic List

GET https://app.scientist.com/api/v2/dynamic_lists/:slug.json"

Use the dynamic list :slug to fetch a specific list.

Create A Dynamic List

POST https://app.scientist.com/api/v2/dynamic_lists/:slug.json

 # POST this JSON to the dynamic_lists endpoint
{
  "items": [
    {
      "value": "a",
      "human_readable_value": "A"
    },
    {
      "value": "b",
      "human_readable_value": "B"
    },
    {
      "value": "c",
      "human_readable_value": "C"
    }
  ]
}

Create a named dynamic list in the system by POST to the dynamic_lists endpoint.

Inventory Items

Multiple Items

GET https://app.scientist.com/api/v2/inventory_items.json

The API V2 /inventory_items.json index endpoint returns a page worth of items. This endpoint accepts 2 parameters.

• query (string): This is a search query. When this is provided the resulting items will be filtered to those matching the query.
• page (integer): Items are returned 20 at a time, you can page through more results by incrementing this value. Default: 1

Single Item

GET https://app.scientist.com/api/v2/inventory_items/9136e1b8-1d5c-4abe-93c1-803bd60cd8bb.json

Returns the data for a single item. The item's UUID is required in the URL.

Organizations

GET https://app.scientist.com/api/v2/organizations.json

Access to organizations records on the marketplace is scoped to the requesting users' administrative domain. A non-administrative user can only access their default or current record using the /organizations/default.json or /organizations/current.json endpoints.

Default Organization

GET https://app.scientist.com/api/v2/organizations/default.json

In some cases, a token-user is associated with more than 1 organization. Use the /default.json endpoint to confirm the default organization for the user.

Current Organization

GET https://app.scientist.com/api/v2/organizations/current.json

When a token is created the user must be authenticated for a specific organization. Use the /current.json endpoint to confirm the current organization for the token.

Proposals

GET https://app.scientist.com/api/v2/proposals.json

Returns a paginated list of proposals for the token-user.

A Specific Proposal

GET https://app.scientist.com/api/v2/proposals/1.json

Returns the requested proposal, subject to the token-user authorization.

Providers

GET https://app.scientist.com/api/v2/providers.json

Query providers using the /providers.json endpoint.

The /providers.json request responds with an object containing the first page of suppliers available at provider_refs, and a facets object keyed by the search terms available to refine subsequent provider queries.

Use the facets values in the response to request relevant lists of providers. See URL Query Parameters for details on API query parameters, paging, sorting and facet filtering.

A Specific Provider

GET https://app.scientist.com/api/v2/providers/:slug.json

Each provider is indexed uniquely by the id or slug found in the response object. Use the id or slug to request details for a spcific provider. The server responds with a provider object keyed by provider.

Update A Specific Provider

PUT https://app.scientist.com/api/v2/providers/:slug.json -d"{\
    "name": "A Provider Name",\
    "year_established": "1982",\
    "number_of_employees": "1000",\
    "service_areas": ["biology", "toxicology"],
    "some_other_key": "should be ignored"
}"

Update a provider by PUT to the providers endpoint with a payload of accepted key-values. The server responds with a results hash with either Applied or Ignored if the request update parameter is not recognized or not allowed.

The webhooks PUT accepts the following parameters:

Provider Associated Wares

GET https://app.scientist.com/api/v2/providers/:provider_id/wares.json

Return an object containing all wares for a specific provider. The wares can be found in the ware_refs property of the response. If there are no provider-ware associations, then the ware_refs is an empty array.

See also Ware Associated Providers

Provider RFI Annotations

GET https://app.scientist.com/api/v2/provider_rfi_annotations.json
GET https://app.scientist.com/api/v2/provider_rfi_annotations.csv

This endpoint retrieves all provider RFI annotations. Specify .csv suffix to return a Comma Separated Text file or .json for a standard JSON response object.

Quote Groups

GET https://app.scientist.com/api/v2/quote_groups/mine.json

Use /quote_groups.json to request the first page of quote group documents visible to the requestor.

Query quote groups using the /quote_groups.json endpoint. In addition to the basic get all and get specific requests, application developers can use facet search facilities to fetch requests. See URL Query Parameters for details on API query parameters and facet searching.

A Quote Group

GET https://app.scientist.com/api/v2/quote_groups/:quote_group_id.json

This endpoint retrieves quote groups associated with a specific quote group identifier. Each quote group is indexed uniquely by the id found in the /quote_groups.json response object. Use id to request a spcific quote group.

Create Note

Owners of quote group records can amend a quote group with a note using the POST verb to the /quote_group/:id/notes.json endpoint.

POST https://app.scientist.com/api/v2/quote_groups/:quote_group_id/notes.json

  {
      "note": {
        "title": "some title text",
        "body": "note body text",
      }
  }

Internal Messages

The API allows you to fetch arrays of documents attached to Quote Groups including Internal Messages, Compliance Manifests and Participating Providers.

GET https://app.scientist.com/api/v2/quote_groups/:quote_group_id/internal_messages.json

Internal Messages returns and array of notes attached to the Quote Group.

Compliance Manifests

GET http://app.scientist.com/api/v2/quote_groups/:quote_group_id/compliance_manifest.json

Returns and array of compliance manifests attached to the Quote Group.

Participating Provider

GET http://app.scientist.com/api/v2/quote_groups/:quote_group_id/participating_provider.json

Returns the last of provider attached presenting a proposal attached to the Quote Group.

Quoted Wares

GET https://backoffice.scientist.com/api/v2/quoted_wares.json

Returns all quoted wares associated with the requesting user. The server responds with an object containing the first page of quoted wares and a facets object. See URL Query Parameters for details on API query parameters and facet searching.

Quoted Wares can be filtered by the following facet names:

• vendor
• status
• requestor
• request_type
• requestor_company
• assignee_emails

A Quoted Ware

GET https://app.scientist.com/api/v2/quoted_ware/:id.json

Each quoted ware is indexed uniquely by the id found in the response object returned by the /quoted_ware.json endpoint. Use id to request a specific quoted ware. The server responds with the quoted ware object.

Invoices

GET https://app.scientist.com/api/v2/quoted_wares/:quoted_ware_id/invoices.json
GET https://app.scientist.com/api/v2/quoted_wares/:quoted_ware_id/invoices/:id.json

The quoted ware collections endpoint responds with an array of the requested Invoice. Fetch individual documents by appending the the appropriate identifier to the endpoint.

Proposals

GET https://app.scientist.com/api/v2/quoted_wares/:quoted_ware_id/proposals.json
GET https://app.scientist.com/api/v2/quoted_wares/:quoted_ware_id/proposals/:id.json

The quoted ware collections endpoint responds with an array of the requested Proposals. Fetch individual documents by appending the the appropriate identifier to the endpoint.

Purchase Orders

GET https://app.scientist.com/api/v2/quoted_wares/:quoted_ware_id/purchase_orders.json
GET https://app.scientist.com/api/v2/quoted_wares/:quoted_ware_id/purchase_orders/:id.json

The quoted ware collections endpoint responds with an array of the requested Purchase Orders. Fetch individual documents by appending the the appropriate identifier to the endpoint.

Messages

{
    "supplier_name": "Grimes Group--4",
    "message_count": 0,
    "quote_group_identifier": "B8A3ED",
    "older_messages_count": null,
    "all_messages": []
}

GET https://app.scientist.com/api/v2/quoted_wares/:quoted_ware_id/messages.json

Fetch Messages attached to Quoted Wares.

Payment Documents

GET https://app.scientist.com/api/v2/quoted_wares/:quoted_ware_id/payment_documents.json

Fetch Payment Documents attached to Quoted Wares.

Users

Users can be members of a Provider or Organization on the marketplace.

GET https://app.scientist.com/api/v2/users.json

A request to /users.json returns an object with an array of users found at user_refs and a facets object keyed by the search terms available to query for specific users.

Access to user records on the marketplace is scoped to the requesting users' administrative domain. A non-administrative user can only access his/her own user record. Administrators of a domain can download all user records for that domain.

User records can be searched by facet name/value. See URL Query Parameters for details on API query parameters and facet searching.

Users can be filtered by the following facet names:

• company
• discipline
• site
• title

Profile

Request details of the user account scoped to your authorization code with /users/profile.json. The server responds with an object keyed by "user".

GET https://app.scientist.com/api/v2/users/profile.json

Wares

GET https://app.scientist.com/api/v2/wares.json

Use the /wares.json endpoint to develop picklists of available services and identify search terms available for querying wares. The /wares.json request responds with an object containing the first page of wares available at ware_refs, and a facets object keyed by the search terms available to refine subsequent provider queries. See URL Query Parameters for details on API query parameters and facet searching.

Wares can be filtered by the following facet names:

• source
• ware_type
• certifications
• countries
• protein_type
• clonality
• cell_source
• species
• technology
• tissue

GET https://app.scientist.com/api/v2/wares.json?q=peptide,antibody

The /wares.json endpoint allows facet and free text search. Search wares by query string such as ?q=search_term. For example, the term ?q=peptide returns all services relating to peptides. Specify multiple query string values by separating search terms by commas.

Detailed lists of available facet values are returned from the index endpoint /wares.json.

A Specific Ware

GET http://app.scientist.com/api/v2/wares/:id.json

Each ware is indexed uniquely by the id found in the response object. Use the id to request details for a specific ware. The server responds with a ware object keyed by ware.

Ware Associated Providers

The marketplace platform allows for many-to-many relationships between Wares and Providers. The wares-providers endpoint allows API users to query providers associated with specific wares, and wares associated to specific providers.

GET https://app.scientist.com/api/v2/wares/:ware_id/providers.json

Return an object containing all providers for a specific ware. The wares can be found in the provider_refs property of the response. If there are no ware-provider associations, then the provider_refs is an empty array.

API users with proper credentials can create and remove wareprovider associations using the POST and DELETE verbs for this endpoint.

See also Provider Associated Wares

Create Ware Provider Association

POST https://app.scientist.com/api/v2/wares/2291/providers/2074.json

Create associations between specific :ware_id and :provider_id with a POST to the /ware/:ware_id/provider/:provider_id endpoint.

Remove Ware Provider Association

DELETE https://app.scientist.com/api/v2/wares/2291/providers/2074.json

Remove associations between specific :ware_id and :provider_id with DELETE at the /ware/:ware_id/provider/:provider_id endpoint.

Webhooks

See Webhooks and Marketplace Events for a high level overview of role of webhooks in the API.

Create

PUT http://app.scientist.com/api/v2/webhook_config.json -d"{\
      "name": "My hook2.",\
      "url": "https://app.client.com/my_callback1",\
      "params": {"key":"value}"},\
      "something_else": "should be igored.",\
      "events": {"all_events": true}}"

A PUT to the /webhook_config.json endpoint creates or updates the webhook configuration. The server responds with a json object keyed by results containing the results of the operation.

The webhooks PUT accepts the following parameters:

Update

Updating and creating use the same endpoint, method, and parameters. Refer to Create a Webhook for details.

Delete

DELETE http://app.scientist.com/api/v2/webhook_config.json

To remove a webhook issue a DELETE request to the /webhook_config.json endpoint. Recall that the webhook configuration is bound to the access_token and associated application.

URL Query Parameters

Paging and Sorting

Certain #index endpoints for example /providers.json, /quote_groups.json provide means for pagination and search. The table below shows the paging, sorting, and form of faceted querying provided by the API.

Free Text Search

An example free text search query string finds all providers with "antibody" keyword associated to their description.

GET http://app.scientist.com/api/v2/provider.json?q=antibody

Free text searches of provider records can be used to generate lists of relevant providers.

Facet Search

A snippet of the "facets" object returned from a providers search request:

{"facets": {
    "starts_with": {
        "doc_count": 17683,
        "doc_count_error_upper_bound": 0,
        "sum_other_doc_count": 0,
        "buckets": [
            {
                "key": "a",
                "doc_count": 1821
            },
            {
                "key": "u",
                "doc_count": 1770
            }
        ]
    },
    "type_of_company_description": {
        "doc_count": 17683,
        "doc_count_error_upper_bound": 0,
        "sum_other_doc_count": 0,
        "buckets": [
            {
                "key": "Small Business (1-10M TTM Revenue)",
                "doc_count": 11786
            },
            {
                "key": "Academic Core Facility",
                "doc_count": 3895
            },
            {
                "key": "New Startup (0-1M TTM Revenue)",
                "doc_count": 1207
            },
            {
                "key": "Mid-Sized Business (10-100M TTM Revenue)",
                "doc_count": 583
            },
            {
                "key": "Large Business (>100M TTM Revenue)",
                "doc_count": 109
            },
            {
                "key": "Consultant",
                "doc_count": 49
            }
        ]
    }
}}

If the response object for the request includes an object keyed by facets, you can use that information to inform a subsequent query. The keys for this object are the available facet names you can use to construct further queries to refine your results. Each facet key provides an object with information about the facet in the database.

The buckets property value holds an array of objects with valid facet_value strings provided in the key field. Use this string as the value argument to your faceted search queries.

Note that While the facet name/value parameters are different depending on the endpoint, the form of query and pagination parameters are consistent across endpoints.

Single Facet Filter

To find providers of type type_of_company_description=Consultant, you would use the following query string:

GET https://app.scientist.com/api/v2/providers.json?facets[type_of_company_description][]=Consultant

Use the response detail from prior requests to inform your facet search filter.

Multiple Facets Filtering

Returns all providers whose names start with "a" or "u".

GET https://app.scientist.com/api/v2/providers.json?facets[starts_with][]=a&facets[starts_with][]=u

Requests can include multiple name/value pairs.

Errors

The API uses the following error codes: