Gofetch- by Goaddon |
gofetch@goaddon.com
|
|
Supported in
|
Use Gofetch to interact with online shops. Import order and product data into your Goaddon database. Modify data directly in the shops, for example create new products or fulfill orders.
You can use Gofetch to collect data from your own shop and build internal functionality on top of the data. Or you can act as a publicly accessible service provider and collect data from any shop who registers for your services. When importing orders and products we will maintain the same data structure between all the ecommerce plaforms you wish to interact with.
You can skip these docs entirely if you are using the Goexplore addon, as explained in the section Using Goexplore instead of your own website .
In these docs we will describe the changes you need to make in your system for our interface to be correctly displayed on your website. The steps can be summarized to:
There are literally no prerequisites or responsibilities that you can't delegate to other addons listed on Goaddon. But we have structured our docs by initially assuming that you are already running a fully functioning website on your own servers, on top of your own database.
For now, it is assumed that:
user
documents belongs to some kind of parent document, we will call them company
documents, or companies throughout these docs.amysoutlet.com
) in your database.There are sections to describe how you circumvent each of the above prerequisites, but to avoid introducing too many concepts at the same time, let us assume you meet these prerequisites.
The end goal is to display our interface on your website, so merchants can sign up and begin to exchange data between their shop and your Goaddon database.
Before the interface can be loaded from our servers and displayed on your website we need to know the users identity. Since the script on your website is executed in the users browser, and the browser is successfully authenticated by your website, the script has access to the users session.
The following process enables your website to share the users session with us:
The following sections will describe how you implement this.
As you have read previously the script needs to communicate with both you and us. We aim to stay in the background, so you should choose a subdomain of yours and point its DNS to our system. This way, the script only communicates with your domain, even though we are involved.
Say you own e.g. example.com , you could choose to point gofetch-api.example.com to our servers. Then you should add this to the HTML code of your web page:
<div id="gf_container"></div> <script type="text/javascript"> var u = "https://gofetch-api.example.com/session_api/v1/assets/script"; if (document.querySelector('script[src="' + u + '"]') === null) { var s = document.createElement('script'); s.type = 'text/javascript'; s.async = true; s.src = u; document.head.appendChild(s); } else { runGf(); } </script>
Now the script will be loaded from our system, through your subdomain. Depending on your framework you may need to modify the script in order to ensure that it runs as desired. For example, in many frameworks it would be beneficial to place it inside the head tag.
As stated earlier, the script needs to communicate with your servers through some endpoint of yours. You are free to choose the path of your endpoint . If you, as in the previous example, own example.com and your website is at www.example.com you could choose to receive this request at https://www.example.com/gofetch_sessions/new
. The request would look like this:
GET /gofetch_sessions/new Host: https://www.example.com Content-Type: application/json Accept: application/json Cookie: <a cookie that authenticates the user who submitted the request>
Based on the Cookie
you should be able to authenticate the user (the actual authentication logic depends on your specific system).
Having authenticated the user you should generate a random session_id
to us, along with the identity of the users company (as mentioned previously, we will assume that your database is structured so a user belongs to a parent document, such as a company). The session_id
could be anything, but you should try and make it at least 36 characters long, e.g. like this uuid: 45756460-fa5a-4b51-acae-c22d6e9dff2a
You should forward these informations by submitting a request to the subdomain you have pointed to our servers. Your request should be authenticated with your accounts session forwarding token , base64 encoded.
Given that your chosen subdomain is gofetch-api.example.com as exemplified previously, and your session forwarding token is 76f7f864-7247-41e3-b39c-e8dd97aa3ef1
, your request should look like this:
POST /interface_api/v1/sessions Host: https://gofetch-api.example.com Content-Type: application/json Accept: application/json Authorization: Basic NzZmN2Y4NjQtNzI0Ny00MWUzLWIzOWMtZThkZDk3YWEzZWYx { "session_id": "45756460-fa5a-4b51-acae-c22d6e9dff2a", "_id": "<the _id of the users parent document, from your Goaddon database>", "remote_id": "<a unique id of the users parent document, from your own database>", "website": "<the website address of the users company>", "email": "<the primary email address of the users company>", "user_email": "<the email address of the user>" }
As seen above the request body should be a JSON hash with the session_id
and informations about the users company (or other parent document):
_id
of the users company, from your Goaddon database. You don't need to provide this if you instead provide us with the remote_id
.remote_id
is an alternative company identifier that you can provide instead of the _id
. It could be anything, just make sure it is unique and never changes.website
should be unique, stripped of https:// and www. For example amysoutlet.com
.email
of the company is optional. For example example@example.com
.user_email
is also optional. For example user@example.com
.You could also try and include the informations as URL params. If you submit your request with the proper Content-Type
and Accept
headers we should be able to parse the URL params.
Please forward the session to us, even if you can't authenticate the user. In that case, only forward the session_id
to us, and we will react accordingly.
# This example assumes you are using the Devise gem for authentication. # Read more at https://github.com/plataformatec/devise. # # current_user in this example represents the authenticated user, if any. # # The example also assumes a user belongs to a company, and that this company # has a unique website. # # The example is trimmed for any context that isn't relevant, we have e.g. # omitted all model fields that are not directly used here. # # app/models/user.rb class User include Mongoid::Document devise :database_authenticatable belongs_to :company, inverse_of: :users end # # app/models/company.rb class Company include Mongoid::Document field :website, type: String validates :website, presence: true, uniqueness: true, format: { with: /\A(?!w{3}\.)[a-z0-9\-]+\.[a-z0-9]+.*\z/, message: "must not contain https:// or www." } has_many :users, inverse_of: :company end # # config/routes.rb Rails.application.routes.draw do # Enable GET requests to "/gofetch_sessions/new". resources :gofetch_sessions, only: [:new] end # # app/controllers/gofetch_sessions_controller.rb class GofetchSessionsController < ApplicationController require "httparty" # Disable Devise's user authentication to allow all requests. skip_before_action :authenticate_user! def new if !request.format.json? head :unprocessable_entity else session_id = SecureRandom.uuid body = {session_id: session_id} # Provide us with the IP address if you want us to verify it. body[:remote_ip] = request.remote_ip if current_user.present? && current_user.company_id.present? company = current_user.company body[:website] = company.website # Either provide us with the company's _id from your Goaddon database... body[:_id] = company._id.to_s # ...or provide us with a unique custom identifier that must never ever change for the company. body[:remote_id] = company.some_unique_custom_id body[:email] = company.email body[:user_email] = current_user.email end HTTParty.post( "https://gofetch-api.example.com/interface_api/v1/sessions", headers: { "Authorization" => "Basic #{Base64.strict_encode64('76f7f864-7247-41e3-b39c-e8dd97aa3ef1')}", "Content-Type" => "application/json" }, body: body.to_json ) render plain: session_id end end end
At this point you have forwarded the session_id
to us along with the identity of the users company. Based on this we will render a customized interface in the browser, so the user can register their shop, which will create a webshop
document in your Goaddon database.
And that's it, you are done.
In previous sections we have assumed that you already have a system/website with certain characteristics. We also promised that all prerequisites could be circumvented/substituted. Before explaining how, we have to introduce our webhooks.
A webhook is a request to your servers that we trigger when certain events occur, for example when:
webshop
document.The webhook will be authenticated with your accounts webhook token , it could be fbbf9e24-a19e-4b41-88d2-bc8fec3fb8a9
, base64 encoded.
You are free to choose the path of your webhook endpoint . If you, as in the previous examples, own e.g. example.com and your own servers can be accessed at www.example.com you could choose to receive this request:
POST /gofetch_api/events Host: https://www.example.com Content-Type: application/json Accept: application/json Authorization: Basic ZmJiZjllMjQtYTE5ZS00YjQxLTg4ZDItYmM4ZmVjM2ZiOGE5 { "event": "<name of event, e.g. created_company or fetched_data>", "_id": "<the _id of the company, from your Goaddon database>", "remote_id": "<the unique company identifier from your own database, if any>", "details": { "detail_x": "<details about the event>" } }
As seen above you will find a JSON hash containing the event type and the details of the company that the webhook concerns.
One of the prerequisites mentioned in the beginning was that you should have a website where users are first required to sign up and register their details before you allow them to interact with our interface. Depending on your project, a better user experience would be achieved by combining the two actions into one.
With the above approach, the interaction between your system and us could be described in these steps:
users
collection and company details in a separate companies
collection.company
document exists with the forwarded details. If so, we will create the new webshop
document belonging to it. If not, we will create company
and webshop
documents in your Goaddon database.As you see from step 1, the burden is on you to make a sign up page available. You can avoid that by displaying the interface on a publicly accesible web page and requiring the visitor to register like this:
company
and webshop
documents in your Goaddon database and trigger a webhook at your API .user
and a parent document like a company
) in your own database.You are free to choose between these approaches . In both cases two sets of documents exists. We will rely on the ones from your Goaddon database, while you will rely on the ones from your own database. This can seem unnecessarily complex, so you should consider building exclusively on your Goaddon database.
One of the prerequisites mentioned in the beginning was that your system runs on top your own database, and that you maintain your own user
documents as well as their parent documents, e.g. company
documents. With this approach you will be authenticating users against your own database. Only when a user submits informations though our interface we will begin to maintain parallel company
documents. You can simplify this by building your entire project on top of your Goaddon database.
The process would be similar to the one described in the previous section about onboarding , except with this approach you only have to create a user
record. The company
record already exists.
# This example assumes you are using the Devise gem for authentication. # Read more at https://github.com/plataformatec/devise. # # The example is trimmed for any context that isn't relevant, we have e.g. # omitted all model fields that are not directly used here. # # app/models/user.rb class User include Mongoid::Document devise :confirmable field :email, type: String validates :email, presence: true, uniqueness: true, format: { with: /\A\S+@\S+\.\S+\z/, message: "must follow the pattern example@example.com" } belongs_to :company, inverse_of: :users end # # app/models/company.rb class Company include Mongoid::Document field :email, type: String has_many :users, inverse_of: :company end # # config/routes.rb Rails.application.routes.draw do namespace :gofetch_api, defaults: {format: :json} do # Expose an endpoint at POST "/gofetch_api/events". resources :events, only: [:create] end end # # app/controllers/gofetch_api/events_controller.rb class GofetchApi::EventsController < ApplicationController # Disable Devise's user authentication to allow all requests. And disable CSRF protection, since browsers are not involved. skip_before_action :authenticate_user!, :verify_authenticity_token def create authorization = Base64.decode64(request.headers["HTTP_AUTHORIZATION"].to_s.sub("Basic ", "")) # Authenticate that the webhook is triggered by Gofetch. if authorization == "fbbf9e24-a19e-4b41-88d2-bc8fec3fb8a9" if params[:event] == "created_company" # Find the company we just created. company = Company.where(_id: params[:_id]).first if company.present? if company.users.size == 0 # Creating a user will trigger Devise to sent a confirmation email. user = company.users.create(email: company.email) end end end end head :no_content end end
Our interface is translated into different languages. If you are missing a language please contact us.
We will default to the first language in your list of allowed languages , but you can override it by declaring a locale in your HTML source code like this:
<script type="text/javascript"> window.gf_locale = "en"; </script>
One of the prerequisites mentioned in the beginning was that you already have a website that authenticates users. If not you should check out the Goexplore addon.
Instead of spending time building your own website, maintaining servers and interacting with Gofetch you could simply subscribe to Goexplore and build your functionality on top of a website that can:
All that is left for you is to build your functionality on top of the data that Gofetch collects into your Goaddon database.
You are free to subscribe to any number of ecommerce platform integrations . The full list is available in the Ecommerce platforms tab. Each integration will have its own pricing, but you will be billed through Goaddon.
Anyone can build and publish an integration, but Goaddon, the company behind Gofetch, has published integrations for some of the most widely used ecommerce platforms, e.g. Shopify and Magento.
In time we expect the list of supported ecommerce platforms to grow.
You may experience problems receiving the request for new session_id
s. Our forward session function is written in vanilla Javascript, but it may for example not be able to capture the session cookie of your user. In that case you could do one of two.
You could (1) add the necesarry tokens to our request, by defining a Javascript object like for example:
window.gf_forward_session_headers = { session_cookie: "foo" };
If that does not work you could (2) override the entire function. You should name the function gfCustomForwardSession
. If, for example, you would like to forward the session with jQuery, your function could look like this:
window.gfCustomForwardSession = function(url, target_function, options) { return $.ajax({ type: "get", dataType: "json", contentType: "application/json", url: url, dataFilter: function(data, dataType) { return null; }, success: function(data, status, xhr) { var session_id = xhr.responseText; gfCallTargetFunction(session_id, target_function, options); }, error: function(xhr, textStatus, errorThrown) { console.log("app error"); } }); };
You will be billed through Goaddon.
Our pricing is based on fee per active account (company) as well as the traffic generated from your integrations.
Each account in your database that has been exchanging data with a shop during a calendar day will incur a daily fee. The daily fee is pro-rated based on a monthly fee of 2.99 EUR. The fee is independent of the number of shop integrations associated with the account. The account will not incur a fee if it has not exchanged any data during the day.
Integrated shops exchange data with you through our servers, and for each time an integration is active we register how much data was handled. One piece of data could be an order or a product. Accompanying data is not charged for, so when exchanging orders, it doesn't matter how many shipments or order lines are exchanged during these interactions. Or when exchanging products, the number of variants and categories doesn't matter.
We distinguish between two types of activity. Outgoing and incoming:
Incoming data is almost always preferred, because it gives you real-time access to the data of an online shop. And since the ecommerce platform is the participant that knows when a new event has occured, it is much more efficient that the synchronization initiative lies within its prerogative. But even in those cases you should not rely entirely on passively receiving data. Some of it might not reach you. Therefore the most sound approach is to primarily rely on receiving data, but ocationally catch potentially lost data by asking for it.
The total number of outgoing requests, incoming webhooks, and the total number of individual pieces of data (e.g. an order or a product) is summarized at the end of the day and, and a fee is derived from that sum. Each type of activity carries the following cost:
Price | |
---|---|
1 outgoing request | 0.0001 EUR |
1 incoming non-product request | 0.00002 EUR |
1 incoming product request | 0.000004 EUR |
1 piece of data, regardless of direction | 0.000002 EUR |
Note from the above that products have a discounted pricing structure, with incoming requests costing less.
This document was last revised 08-03-2022.
The Gofetch addon (“Gofetch” or “Addon”) is offered by Goaddon ApS (“Goaddon”, “we”, “us”, “our”). This agreement (“Addon Agreement”) is a supplement to the agreement (“Agreement”) between you (the “Account”) and Goaddon. When subscribing to the Addon, you enter the Account into this Addon Agreement and may use our services (“Addon Services”). The Agreement supersedes the Addon Agreement. Do not subscribe to the Addon unless you understand and agree to this Addon Agreement in its entirety.
Upon entering into the Addon Agreement the Account may access and use the Addon Services, constrained by the terms set forth by the Agreement and subsequently the Addon Agreement.
The Addon Services include (1) integrations with third party online shops (“Integrations”) and (2) support (“Addon Support”).
To provide Integrations, we make available a number of integration relays (“Relays”, each a “Relay”) that can relay data between you and shops that are owned and operated by third parties (your “Customers”, each a “Customer”). Each Relay facilitates the integration with a specific type of third-party ecommerce software, on which Customers shops run.
If you subscribe the Account to this Addon, we will make available to the Account, an interface that you can embed on your website to allow Customers to choose a Relay that integrates with their type of ecommerce software, and then register themselves. Upon a Customer´s registration, we will save the Customers shop credentials in your database. We will, according to your instructions and through Relays, use the credentials of registered shops to perform actions such as (1) collecting data from a shop and saving it in your database, and (2) providing a shop with data prepared by you. We will only hold data obtained during this process while using it to perform the Addon Services, and we will not store or backup the data ourselves. We may store copies of the Customers shop credentials in our own systems to offload your database. We will encrypt shop credentials before saving them.
If you subscribe the Account to Addon Support, we will provide you with Addon Support in accordance with the support policy described on the subscription page of this Addon. We calculate fees on a per-minute basis.
Subscribing the Account to this Addon does not entitle you to free support. If the Account is not subscribed to, or prepared to pay for Addon Support, we may refuse to address your support enquiries.
When you subscribe to Addon Services, all activity related to Integrations will be carried out on servers located in the zone you have chosen for the Account. All data related to the Account will also be stored on servers in this zone. This includes data shared by Goaddon with Gofetch, such as database credentials and data encryption keys.
We cannot guarantee that an integration made available by a Relay is compatible with all installations, variations or versions of the third-party ecommerce software it relays to. If the use of a Relay requires that software developed by the Relay is installed in the shop, we cannot be held responsible for any damages on the functionality of, or data in, a shop during or after installation of the Relay´s software. It is your responsibility to ensure that any such installation is carried out by personal with sufficient expertise to install the software and capabilities to quickly restore the shop to its original state in case of an unintended installation outcome. Any Relays’ software is provided on an "AS IS" and "AS AVAILABLE" basis and it comes with no representation or warranty of any kind.
You can commission us to install a Relay´s software in a shop by subscribing to Addon Support. We will advise you about which precautions and safety measures should be undertaken before, during and after we attempt to install the software, but you remain responsible for determining to what degree they should be implemented. We are not liable to you for any indirect, incidental, special, consequential or exemplary damages, including damages for loss of revenue or profits, customers, goodwill, use or data arising out of unintended consequences of a failed installation attempt carried out by us, and we are not responsible for any compensation, reimbursement or direct damages arising in connection with it. Our liability is limited to the amount that you have actually paid us under to carry out the installation. You shall defend, indemnify, and hold harmless us, from and against any claims, damages, losses, liabilities, costs, and expenses (including reasonable legal fees) arising out of or relating to any third party claim concerning unintended consequences of a failed installation attempt commissioned by you and carried out by us.
We cannot guarantee an uninterrupted integration between you and third-party shops. It is your responsibility to monitor the state of your integrations, and to resolve integration interruptions with the Customer. We will only participate in the resolution process under the terms that applies to Addon Support, even if the only solution to the problem is for us to modify our own source code or our own Relays’ software.
We cannot guarantee that data relayed between you and third-party ecommerce software is consistent with its data source, or that it represents the full state of its data source. You should incorporate a sufficient error tolerance into your application of the data. It is your responsibility to use the data with caution and avoid unintended and irreversible consequences of data corruption, and to take into account that data can be incorrectly interpreted when exchanged between systems.
When you subscribe to an addon, Goaddon provisions a database user that enables the addon to access your Goaddon database.
The addon will use this access to do whatever you subscribed for them to do.
At any point in time you can unsubscribe and revoke their database access.
The addon gets read/write access to the entire database. Below you can see what collections this particular addon reads from, writes to or indexes.
Please read carefully through the descriptions below. From it you should be able to determine if the addon uses MongoDB in a way that conflicts with your usage, but it is also where you can familiarize youself with what interesting data the addon contributes with.
For each attribute in a collection you can see if the addon is encrypting the data before saving it in MongoDB. If that is the case you can decrypt the attribute using the encryption keys associated with your account.
Description
When a vistor visits your website and submits the credentials to his shop through our interface we will test the validity of these credentials.
The visitor only gets to proceed if the test succeeds. But in any case the test result will be stored in an auth
document.
If, upon a successfull test, the visitor proceeds, a webshop
document will be created that belongs to a company
. And the auth
document will be destroyed.
Attributes
Name | Type | Encrypted | Description |
---|---|---|---|
_id |
BSON::ObjectId | - | |
created_at |
Time | - | |
error |
Array | No | null unless an error occured. Otherwise it will contain informations that might help solve the problem. If the shop responded with a 500 error the field could have the value [{name: 'response_code', value: '500'}] . All values are encrypted. |
log |
Hash | No | During the test the log will be recurringly updated with information about the progress of the test, e.g. {klasses: {orders: 8, shipments: 2}} . |
relay_id |
BSON::ObjectId | - | |
remote_ip |
String | Yes | The IP address of the visitor who initiated the test. |
setup_config |
Hash | Yes | Informations about what data was fetched during the test, e.g. {shop_ids: [{remote_id: '1', name: 'Default store'}], statuses: [{remote_id: '1', name: 'New'}, {remote_id: '2', name: 'Dispatched' }]} . The informations will be presented to the person who entered the credentials in the first place. |
status |
String | No | The auth will eventually end up as field error or success . |
status_description |
String | No | null unless an error occured. Otherwise this field will summarize the error. |
updated_at |
Time | - | |
webshop_config |
Hash | Yes | This field contains the credentials and other informations submitted by the visitor who initiated the test, e.g. {api_key: 'foo'} . |
webshop_id |
BSON::ObjectId | - |
Indexes
Key | Name | Unique | Sparse |
---|---|---|---|
{"_id":1,"relay_id":1} |
No | No | |
{"relay_id":1} |
No | No |
Description
A product
can belong to many categories
.
Attributes
Name | Type | Encrypted | Description |
---|---|---|---|
_id |
BSON::ObjectId | - | |
breadcrumbs |
Array | Yes | |
company_id |
BSON::ObjectId | - | |
description_1 |
String | Yes | E.g. '<p>Shoes</p>' . |
description_2 |
String | Yes | E.g. '<p>Our hottest shoes</p>' . |
images |
Array | Yes | E.g. [{'remote_id': '1234-1', 'url': 'https://example.com/images/shoes.png', 'title': 'Shoes', 'position': 1}] . It's depends on the ecommerce platform if it's possible to present the url's with domain and with https:// and www.. |
meta_description |
String | Yes | E.g. 'Buy the hottest shoes' . |
meta_title |
String | Yes | E.g. 'Buy shoes' . |
name |
String | Yes | E.g. 'Shoes' . |
parent_category_id |
BSON::ObjectId | - | |
path |
String | Yes | E.g. 'shoes' . |
published |
Boolean | - | Either true or false . |
published_scope |
String | No | The scope of the category, e.g. 'web' or global``. |
remote_id |
String | Yes | A unique internal ID that is used in the shop. |
searchable |
Boolean | - | Either true or false . |
sort_order |
String | No | E.g. manual . |
status |
String | No | E.g. 'active' . |
template |
String | Yes | E.g. 'shoes' . |
updated_at |
Time | - | |
webshop_id |
BSON::ObjectId | - |
Indexes
Key | Name | Unique | Sparse |
---|---|---|---|
{"webshop_id":1,"remote_id":1} |
Yes | No | |
{"webshop_id":1} |
No | No |
Description
Everything except auths
belongs to a company
.
When a visitor successfully registers through the Gofetch interface the first thing that gets created is a company
and a webshop
that belongs to it.
If a company
is destroyed it is important to make sure all documents that belongs to it also gets destroyed.
Attributes
Name | Type | Encrypted | Description |
---|---|---|---|
_id |
BSON::ObjectId | - | |
email |
String | No | E.g. 'example@example.com' . |
locale |
String | No | When information is displayed through our interface to whoever has access to this company , this field will determine what language we will use. If it is empty we will use a default language selected by you. |
remote_id |
String | No | This field represents the unique ID that you would like the company to be identified with. If you are maintaining a parallel database with your own records (instead of just relying on the company record in your Goaddon database) the remote_id field is where your internally used ID of the company is stored. Read more about our this in our docs. |
website |
String | No | E.g. 'example.com' or 'some-online-store.example.com' , without http(s)// and www.. |
Indexes
Key | Name | Unique | Sparse |
---|---|---|---|
{"remote_id":1} |
Yes | Yes | |
{"website":1} |
Yes | Yes |
Description
orders
belongs to countries
through its fields billing_country_id
and shipping_country_id
.
Attributes
Name | Type | Encrypted | Description |
---|---|---|---|
_id |
BSON::ObjectId | - | |
company_id |
BSON::ObjectId | - | |
name |
String | No | The name of the country could be anything, and does not follow any standards. It's purely determined by the webshop where the data is fetched from. Example: 'US' , 'United States' or 'ISO 3166' . |
remote_id |
String | No | |
updated_at |
Time | - | |
webshop_id |
BSON::ObjectId | - |
Indexes
Key | Name | Unique | Sparse |
---|---|---|---|
{"webshop_id":1,"remote_id":1} |
Yes | No | |
{"webshop_id":1} |
No | No |
Description
translation missing: en.admin_api.collections.descriptions.credit_notes
Attributes
Name | Type | Encrypted | Description |
---|---|---|---|
_id |
BSON::ObjectId | - | |
amount |
Float | - | The total credited amount, e.g. 100.99 . |
company_id |
BSON::ObjectId | - | |
created_at |
Time | - | The credit note date. |
order_id |
BSON::ObjectId | - | |
order_lines |
Array | Yes | The order lines associated with the credit note, e.g. [{'variant_sku': '1234-XS', 'quantity': 2, 'amount': 299.99, 'variant_id': BSON::ObjectId('60df0fe43ab42f728bd0d269')}] |
order_number |
String | No | |
payment_amount |
Float | - | The amount credited for payment, e.g. 1.00 |
refunded_amount |
Float | - | The amount refunded to the payment card, e.g. 100.99 . |
remote_id |
String | Yes | The ID of the credit note, e.g. 10001 . |
returned_amount |
Float | - | The amount returned by other means than through a payment card, e.g. 100.99 . |
shipping_amount |
Float | - | The amount credited for shipping, e.g. 1.00 |
updated_at |
Time | - | |
webshop_id |
BSON::ObjectId | - |
Indexes
Key | Name | Unique | Sparse |
---|---|---|---|
{"company_id":1,"order_number":1,"created_at":1,"remote_id":1} |
Yes | No | |
{"company_id":1,"order_number":1} |
No | No | |
{"webshop_id":1} |
No | No |
Description
customers
are mainly defined by their email
. Whenever we create a new order
we create a customer
with the same email
if one does not exist already.
So orders
with the same email
will also have the same customer_id
.
Attributes
Name | Type | Encrypted | Description |
---|---|---|---|
_id |
BSON::ObjectId | - | |
accepts_marketing |
Boolean | - | Either true or false . |
addresses |
Array | Yes | An array of the customers addresses, e.g. [{'first_name': 'John', 'last_name': 'Doe', 'name': 'John Doe', 'personal_identifier': '0123456789', 'company': 'European Commission', 'vat_number': 'BE0123456789', 'address_1': 'Rue de la Loi 130', 'address_2': '1st floor', 'zip_code': '1049', 'city': 'Brussels', 'province_code': 'BE-BRU', 'province': 'Capital Region', 'phone': '+3201234567', 'country_id': '60d472973ab42f5ff6a25a72', 'billing_default': true, 'shipping_default': false}] |
company |
String | Yes | E.g. 'European Commission' . |
company_id |
BSON::ObjectId | - | |
company_note |
String | Yes | If the ecommerce platform supports internal communication about a customer that communication will be written into this field. |
confirmed |
Boolean | - | Whether a confirmation has been sent to the customer, for example by email, either true or false . Depending on the individual ecommerce platform this could also indicate if the customer has confirmed the recieved email. |
created_at |
Time | - | |
currency |
String | No | E.g. 'EUR' or '840' . This field don't follow any particular standards. |
email |
String | Yes | E.g. 'john.doe@example.com' . |
first_name |
String | Yes | E.g. 'John' . |
group |
String | No | The customer group where the customer belongs in the shop, e.g. 'default' . |
invited |
Boolean | - | Whether the customer has been invited to confirm the account, for example by email, either true or false . |
language |
String | No | The preferred language, e.g. 'nl-BE' or 'nl' . |
last_name |
String | Yes | E.g. 'Doe' . |
password |
String | Yes | Probably not not provided in clear text by the shop, if provided at all, e.g. 'Doe-shall>n0t.pass' . |
personal_identifier |
String | Yes | A personal social security number, tax identification or similar, e.g. '0123456789' . |
remote_id |
String | Yes | An internal ID used by the shop. If no such ID exists in the shop, the email of the customer will be used instead. |
tags |
Array | No | E.g. ['vip'] . |
updated_at |
Time | - | |
vat_class |
String | No | The VAT settings of the order, e.g. 'default' . VAT settings can also be applied to individual order order lines. |
vat_number |
String | Yes | E.g. 'BE0123456789' . |
vat_pct |
Float | - | The applied VAT rate for the order, e.g. 0.25 . |
webshop_id |
BSON::ObjectId | - |
Indexes
Key | Name | Unique | Sparse |
---|---|---|---|
{"webshop_id":1,"remote_id":1} |
Yes | No | |
{"webshop_id":1} |
No | No |
Description
An order
belongs_to a delivery_method
. We don't create a delivery_method
until we have had the opportunity to create an order
that utilizes it. So a delivery_method
that has been created externally will remain unknown to us until someone uses it.
Attributes
Name | Type | Encrypted | Description |
---|---|---|---|
_id |
BSON::ObjectId | - | |
company_id |
BSON::ObjectId | - | |
name |
String | No | E.g. 'DHL express' or 'Pick up in store' . |
remote_id |
String | No | An internal ID used by the shop. |
updated_at |
Time | - | |
webshop_id |
BSON::ObjectId | - |
Indexes
Key | Name | Unique | Sparse |
---|---|---|---|
{"webshop_id":1,"remote_id":1} |
Yes | No | |
{"webshop_id":1} |
No | No |
Description
An invoice
belongs to an order.
Attributes
Name | Type | Encrypted | Description |
---|---|---|---|
_id |
BSON::ObjectId | - | |
amount |
Float | - | The total invoiced amount, e.g. 100.99 . |
captured_amount |
Float | - | The amount captured from the payment card, e.g. 100.99 . |
company_id |
BSON::ObjectId | - | |
created_at |
Time | - | The invoice date. |
order_id |
BSON::ObjectId | - | |
order_lines |
Array | Yes | The order lines associated with the invoice, e.g. [{'variant_sku': '1234-XS', 'quantity': 2, 'amount': 299.99, 'variant_id': BSON::ObjectId('60df0fe43ab42f728bd0d269')}] |
order_number |
String | No | |
paid_amount |
Float | - | The amount paid by other means than with a payment card, e.g. 100.99 . |
payment_amount |
Float | - | The amount invoiced for payment, e.g. 1.00 |
remote_id |
String | Yes | The ID of the invoice, e.g. 10001 . |
shipping_amount |
Float | - | The amount invoiced for shipping, e.g. 1.00 |
updated_at |
Time | - | |
webshop_id |
BSON::ObjectId | - |
Indexes
Key | Name | Unique | Sparse |
---|---|---|---|
{"company_id":1,"order_number":1,"created_at":1,"remote_id":1} |
Yes | No | |
{"company_id":1,"order_number":1} |
No | No | |
{"webshop_id":1} |
No | No |
Description
An order_line
belongs to an order
.
Attributes
Name | Type | Encrypted | Description |
---|---|---|---|
_id |
BSON::ObjectId | - | |
company_id |
BSON::ObjectId | - | |
order_id |
BSON::ObjectId | - | |
order_number |
String | No | The same value as is stored in the order it belongs to. We are duplicating it here for internal purposes. |
price |
Float | - | The total amount paid for a single unit in the order_line , incl. all taxes. If the price is 149.99 and the quantity is 2 , the value of this field will be 149.99 . |
product_name |
String | Yes | order_lines belongs to variants , who belongs to products . Through this connection you can trace back the details behind the order_line . The product_name field of the order line is independed of this though. A situation could occur where the product e.g. has the name 'Glove' , but the order_line has the product_name 'Golong Shoes (XS)' . Over time the details of the product might change, while the product_name of the order_line will stay the same. |
quantity |
Integer | - | E.g. 2 . |
remote_id |
String | Yes | An internal ID used by the shop. |
updated_at |
Time | - | |
variant_id |
BSON::ObjectId | - | |
variant_sku |
String | Yes | The same value as is stored in the variant it belongs to. But a situation could occur where the variant don't exist, and the variant_sku of the order_line is the only reference to what has been bought. |
vat_class |
String | No | |
vat_pct |
Float | - | |
webshop_id |
BSON::ObjectId | - |
Indexes
Key | Name | Unique | Sparse |
---|---|---|---|
{"company_id":1,"order_number":1,"variant_sku":1,"remote_id":1} |
Yes | No | |
{"order_id":1} |
No | No | |
{"webshop_id":1,"order_number":1} |
No | No | |
{"webshop_id":1} |
No | No |
Description
An order
belongs to both a company
and a webshop
and is best recognized by its order_number
.
Attributes
Name | Type | Encrypted | Description |
---|---|---|---|
_id |
BSON::ObjectId | - | |
accepts_marketing |
Boolean | - | Either true or false . |
billing_address_1 |
String | Yes | E.g. 'Rue de la Loi 130' . |
billing_address_2 |
String | Yes | E.g. '1st floor' . |
billing_city |
String | Yes | E.g. 'Brussels' . |
billing_company |
String | Yes | E.g. 'European Commission' . |
billing_country_id |
BSON::ObjectId | - | This field will reference the _id of a country . |
billing_first_name |
String | Yes | E.g. 'John' . Some ecommerce platforms don't store first and last names separately, instead the billing_name will be used. |
billing_last_name |
String | Yes | E.g. 'Doe' . Some ecommerce platforms don't store first and last names separately, instead the billing_name will be used. |
billing_name |
String | Yes | E.g. 'John Doe' . |
billing_personal_identifier |
String | Yes | A personal social security number, tax identification or similar, e.g. '0123456789' . |
billing_phone |
String | Yes | E.g. '+3201234567' . Phone numbers don't follow any particular standards. |
billing_phone_short |
String | Yes | A sanitized version of the phone number, e.g. '1201234567' . |
billing_province |
String | Yes | E.g. 'Capital Region' . |
billing_province_code |
String | Yes | E.g. 'BE-BRU' . |
billing_vat_number |
String | Yes | E.g. 'BE0123456789' . |
billing_zip_code |
String | Yes | E.g. '1049' . |
browser_accept_language |
String | Yes | The languages accepted by the browser, e.g. 'en-US,en;q=0.9' . |
browser_height |
Integer | - | The height of the browser, e.g. 1320 . |
browser_ip |
String | Yes | The IP address of the customer who created the order, e.g. '00.00.000.000' . |
browser_session_hash |
String | Yes | The calculated session hash of the browser, e.g. '50e05590a8e93af24aa35ce0b9c8b98b' . |
browser_user_agent |
String | Yes | The user browser agent, e.g. 'Mozilla/5.0 (Macintosh; Intel Mac OS X 10_13_1)...' . |
browser_width |
Integer | - | The width of the browser, e.g. 1280 . |
cancellation_reason |
String | Yes | E.g. 'Changed their mind' . |
cancelled_at |
Time | - | If the order is updated with the state of 'cancelled' a timestamp will reflect the time where the state was updated. |
cart_token |
String | Yes | E.g. '49b83b8de356e4bbfc589549d3ed2f62' . |
checkout_token |
String | Yes | E.g. '9f3a631e8173c56d2991c9ea370523e7' . |
closed_at |
Time | - | If the order is updated with the state of 'closed' a timestamp will reflect the time where the state was updated. |
company_id |
BSON::ObjectId | - | |
company_note |
String | Yes | If the ecommerce platform supports internal communication about an order that communication will be written into this field. As time progress the value of this field might change. |
created_at |
Time | - | This timestamp will reflect the time where the order was not only created, but also paid. The definition of paid depends on nature of the payment. If the order was created with a payment card or other form of payment that can be authenticated imediately the order is not considered paid until the authentication has happened. Until then this field will be null . If, on the other hand, the payment_method is something a la invoice, bank transfer, etc., then the order will get a timestamp in this field, regardless what subsequently happens with the actual payment. |
created_by |
String | No | E.g. 'shop_api' . |
currency |
String | No | E.g. 'EUR' or '840' . This field don't follow any particular standards. |
customer_id |
BSON::ObjectId | - | |
customer_note |
String | Yes | If the ecommerce platform allows the purchaser to write a note or comment while ordering that note will be written into this field. |
delivery_method_id |
BSON::ObjectId | - | |
delivery_price |
Float | - | E.g. 4.5 . |
discount_amount |
Float | - | The discount amount that was be deducted from the price of the order, e.g. 10.5 . |
discount_codes |
Array | No | E.g. ['vip'] . |
email |
String | Yes | E.g. 'john.doe@example.com' . |
events |
Array | Yes | An array of events, e.g. [{'created_at': '2022-12-31T23:59:59+01:00', 'status': 'open', 'comment': 'Payment authorized'}] . |
initialized_at |
Time | - | In contrast to the created_at field, this field will contain a timestamp that reflects the creation of the order , regardless the status of the payment. |
landing_page |
String | No | E.g. 'https://example.com/shoes' . |
language |
String | No | The preferred language, e.g. 'nl-BE' or 'nl' . |
order_number |
String | No | The unique ID in the webshop , e.g. '1001' . |
payment_method_id |
BSON::ObjectId | - | |
payment_price |
Float | - | E.g. 0.1 . |
price |
Float | - | E.g. 294.08 . The price should ideally be equal to the sum of the price of all order_lines , plus the delivery_price and payment_price , minus the discount_amount . That is not always the case though, as some ecommerce platforms may have pricing structures that can't be shared with us properly. |
reference |
String | No | E.g. 'Sales rep. 1559' . |
referer_page |
String | No | E.g. 'https://google.com?s=shoes' . |
refunded_at |
Time | - | If the order is updated with the state of 'refunded' a timestamp will reflect the time where the state was updated. |
remote_id |
String | Yes | An internal ID used by the shop. |
shipping_address_1 |
String | Yes | E.g. 'Rue de la Loi 175' . |
shipping_address_2 |
String | Yes | E.g. '2nd floor' . |
shipping_city |
String | Yes | E.g. 'Brussels' . |
shipping_company |
String | Yes | E.g. 'European Council' . |
shipping_country_id |
BSON::ObjectId | - | This field will reference the _id of a country . |
shipping_first_name |
String | Yes | E.g. 'Jane' . Some ecommerce platforms don't store first and last names separately, instead the shipping_name will be used. |
shipping_last_name |
String | Yes | E.g. 'Doe' . Some ecommerce platforms don't store first and last names separately, instead the shipping_name will be used. |
shipping_name |
String | Yes | E.g. 'Jane Doe' . |
shipping_personal_identifier |
String | Yes | A personal social security number, tax identification or similar, e.g. '0123456789' . |
shipping_phone |
String | Yes | E.g. '+3212345678' . Phone numbers don't follow any particular standards. |
shipping_phone_short |
String | Yes | A sanitized version of the phone number, e.g. '1212345678' . |
shipping_province |
String | Yes | E.g. 'Capital Region' . |
shipping_province_code |
String | Yes | E.g. 'BE-BRU' . |
shipping_vat_number |
String | Yes | E.g. 'BE1234567890' . |
shipping_zip_code |
String | Yes | E.g. '1048' . |
state |
String | No | Represents the interpreted state of the order. It will either be 'open' , 'closed' , 'cancelled' or 'refunded' . |
status_id |
BSON::ObjectId | - | |
tags |
Array | No | E.g. ['vip'] . |
updated_at |
Time | - | |
vat_class |
String | No | The VAT settings of the order, e.g. 'default' . VAT settings can also be applied to individual order order lines. |
vat_pct |
Float | - | The applied VAT rate for the order, e.g. 0.25 . |
webshop_id |
BSON::ObjectId | - |
Indexes
Key | Name | Unique | Sparse |
---|---|---|---|
{"company_id":1,"order_number":1} |
Yes | No | |
{"webshop_id":1,"initialized_at":-1} |
No | No | |
{"webshop_id":1,"state":1,"initialized_at":1} |
No | No | |
{"webshop_id":1} |
No | No |
Description
An order
belongs_to a payment_method
. We don't create a payment_method
until we have had the opportunity to create an order
that utilizes it. So a payment_method
that has been created externally will remain unknown to us until someone uses it.
Attributes
Name | Type | Encrypted | Description |
---|---|---|---|
_id |
BSON::ObjectId | - | |
company_id |
BSON::ObjectId | - | |
name |
String | No | E.g. 'VISA' , 'Bank transfer' or 'Cash when pick up in store' . |
remote_id |
String | No | An internal ID used by the shop. |
updated_at |
Time | - | |
webshop_id |
BSON::ObjectId | - |
Indexes
Key | Name | Unique | Sparse |
---|---|---|---|
{"webshop_id":1,"remote_id":1} |
Yes | No | |
{"webshop_id":1} |
No | No |
Description
A product
should not be considered a physical object that you can buy. Instead products
have variants
for that purpose. Even if the real life item don't really have variations the product
will still have a variant
.
The product
is used to store the informations that its variants
have in common.
Attributes
Name | Type | Encrypted | Description |
---|---|---|---|
_id |
BSON::ObjectId | - | |
allow_backorders |
Boolean | - | Either true or false . |
before_price |
Float | - | The before price incl. all taxes, e.g. 399.99 or null . |
campaign |
String | Yes | The name of a campaign the the product is assigned to, e.g. 'arrivals' . |
campaign_finished_at |
Time | - | The time of a campaign to finish, e.g. '2023-02-28T23:59:59+01:00' . |
campaign_started_at |
Time | - | The time of a campaign to start, e.g. '2022-07-31T23:59:59+02:00' . |
category_ids |
Array | No | BSON::ObjectId's of the categories the product belongs to. |
company_id |
BSON::ObjectId | - | |
cost_price |
Float | - | The cost price excl. all taxes, e.g. 99.99 or null . |
currency |
String | No | E.g. 'USD' or '840' . This field don't follow any particular standards. |
description_1 |
String | Yes | E.g. '<p>Sporty Golong shoes</p>' . |
description_2 |
String | Yes | E.g. '<p>The hottest Golong shoes from our collection</p>' . |
description_3 |
String | Yes | E.g. '<ul><li>Material: Leather</li></ul>' . |
height |
Integer | - | E.g. 20 . |
images |
Array | Yes | E.g. [{'remote_id': '1234-1', 'url': 'https://example.com/images/1234-1.png', 'title': 'Golong shoes', 'position': 1}] . It's depends on the ecommerce platform if it's possible to present the url's with domain and with https:// and www.. |
in_stock_message |
String | No | E.g. 'In stock' . |
length |
Integer | - | E.g. 30 . |
low_stock_limit |
Integer | - | E.g. 1 . |
manage_stock |
Boolean | - | Either true or false . |
manufacturer |
String | Yes | The producer or brand owner of the product. |
max_quantity |
Integer | - | The maximum quantity allowed for each purchase, e.g. 999 . |
meta_description |
String | Yes | E.g. 'Buy the hottest Golong shoes' . |
meta_title |
String | Yes | E.g. 'Buy Golong shoes' . |
min_quantity |
Integer | - | The minimum quantity allowed for each purchase, e.g. 1 . |
name |
String | Yes | E.g. 'Golong Shoes' . |
no_stock_message |
String | No | E.g. 'Not in stock' . |
offer_finished_at |
Time | - | The time of an offer to finish, e.g. '2023-02-28T23:59:59+01:00' . |
offer_price |
Float | - | The offer price incl. all taxes, e.g. 149.99 or null . |
offer_started_at |
Time | - | The time of an offer to start, e.g. '2022-07-31T23:59:59+02:00' . |
path |
String | Yes | E.g. 'golong-shoes' . |
price |
Float | - | The price incl. all taxes, e.g. 299.99 . |
published |
Boolean | - | Either true or false . |
published_scope |
String | No | The scope of the product, e.g. 'web' or global``. |
related_product_ids |
Array | No | |
searchable |
String | No | Either true or false . |
size_unit |
String | No | E.g. 'cm' . |
sku |
String | Yes | While a product shouldn't be considered a physical object that you can buy, it still has a sku , which is short for Stock keeping unit. If a product only have one variant it is likely that they both have the same sku . This could be anything, e.g. '1234' . |
sku_2 |
String | Yes | An internal ID used by the shop. |
sku_3 |
String | Yes | An internal ID used by the shop. |
status |
String | No | E.g. 'active' . |
tags |
Array | Yes | E.g. ['shoes'] . |
template |
String | Yes | E.g. 'shoes' . |
type |
String | No | E.g. 'advanced' |
unboxed_height |
Integer | - | E.g. 15 . |
unboxed_length |
Integer | - | E.g. 25 . |
unboxed_weight |
Integer | - | E.g. 600 . |
unboxed_width |
Integer | - | E.g. 15 . |
updated_at |
Time | - | |
url |
String | Yes | E.g. 'https://example.com/products/1234' . It depends on the ecommerce platform if it is possible to present the url with domain. |
vat_class |
String | No | The VAT settings of the product, e.g. 'default' . |
vat_pct |
Float | - | The VAT pct of the product, e.g. 0.25 . |
webshop_id |
BSON::ObjectId | - | |
weight |
Integer | - | E.g. 1000 . |
weight_unit |
String | No | E.g. 'g' . |
width |
Integer | - | E.g. 20 . |
Indexes
Key | Name | Unique | Sparse |
---|---|---|---|
{"webshop_id":1} |
No | No | |
{"webshop_id":1,"sku":1} |
Yes | No |
Description
When an order
is closed by the owner of the webshop
the state
of the order
will change from open
to closed
, and the closed_at
field in the order
will be filled with a timestamp. But for the purpose of storing additional information a shipment
will be created.
Additionally a situation could occur where a shipment
is created without the order
being closed, e.g. if not all order lines are available for dispatch and have to be split into multiple rounds.
The shipment
might hold informations about what order_lines
are included in it.
Attributes
Name | Type | Encrypted | Description |
---|---|---|---|
_id |
BSON::ObjectId | - | |
address_1 |
String | Yes | |
address_2 |
String | Yes | |
city |
String | Yes | |
company |
String | Yes | |
company_id |
BSON::ObjectId | - | |
country_id |
BSON::ObjectId | - | |
courier |
String | No | E.g. 'DHL express' . This field don't follow any particular standards, and can even vary between webshops within the same platform. |
created_at |
Time | - | A timestamp that represents the time where the shipment was created. |
first_name |
String | Yes | |
last_name |
String | Yes | |
name |
String | Yes | |
order_id |
BSON::ObjectId | - | |
order_lines |
Array | Yes | The order lines associated with the shipment, e.g. [{'variant_sku': '1234-XS', 'quantity': 2, 'variant_id': BSON::ObjectId('60df0fe43ab42f728bd0d269')}] |
order_number |
String | No | The same value as is stored in the order it belongs to. We are duplicating it here for internal purposes. |
province |
String | Yes | |
province_code |
String | Yes | |
remote_id |
String | Yes | An internal ID used by the shop. |
tracking_number |
String | Yes | E.g. 'DFSAQWDGR' . This field don't follow any particular standards. |
tracking_number_updated_at |
Time | - | A timestamp that represents the time where the shipment was updated with a tracking number. |
updated_at |
Time | - | |
webshop_id |
BSON::ObjectId | - | |
zip_code |
String | Yes |
Indexes
Key | Name | Unique | Sparse |
---|---|---|---|
{"company_id":1,"order_number":1,"created_at":1,"remote_id":1} |
Yes | No | |
{"webshop_id":1,"order_number":1} |
No | No | |
{"webshop_id":1} |
No | No |
Description
The statuses
that exists vary between ecommerce platforms, and can even vary between webshops
within the same ecommerce platform. In order to determine what the status
represents the owner of the webshop
can register the purpose of each status
through the Gofetch interface. It could either represent closed
, cancelled
or refunded
. Any status that isn't defined specifically will be assumed to represent open
.
We don't create a status
until we have had the opportunity to create an order
that utilizes it. So a status
that has been created externally will remain unknown to us until an order
has been placed into that status
.
When we register that an order
has a status that unknown to us we will create a new status
. And then we will change the orders
status_id
to reference the new status
. If the new status
has been registered by the merchant to represent a closed, cancelled or refunded order state, we will update the orders
state
field to reflect that.
Attributes
Name | Type | Encrypted | Description |
---|---|---|---|
_id |
BSON::ObjectId | - | |
company_id |
BSON::ObjectId | - | |
name |
String | No | E.g. 'Processing' or 'Payment captured' . |
remote_id |
String | No | An additional ID. |
updated_at |
Time | - | |
webshop_id |
BSON::ObjectId | - |
Indexes
Key | Name | Unique | Sparse |
---|---|---|---|
{"webshop_id":1,"remote_id":1} |
Yes | No | |
{"webshop_id":1,"_id":1} |
No | No | |
{"webshop_id":1} |
No | No |
Description
The availability of a variant
depends on two factors. The variant
's stock
field, which is an Integer. And the stock_message
, which is defined by the name
field. This could e.g. be 'In stock'
or 'Not in stock'
.
Not all ecommerce platforms supports this, so you could very well experience that a variant
that don't have a stock_message
.
Attributes
Name | Type | Encrypted | Description |
---|---|---|---|
_id |
BSON::ObjectId | - | |
company_id |
BSON::ObjectId | - | |
remote_id |
String | No | E.g. 'In stock' or 'Not in stock' . |
updated_at |
Time | - | |
webshop_id |
BSON::ObjectId | - |
Indexes
Key | Name | Unique | Sparse |
---|---|---|---|
{"webshop_id":1,"remote_id":1} |
Yes | No | |
{"webshop_id":1} |
No | No |
Description
You will inevitably experience that some merchants run into problems while trying to register themselves through the Gofetch interface. And often you will have to involve the relay who maintains the integration. That is done by the merchant opening a ticket
through the Gofetch interface.
The ticket
will be available to you, and the relay if you choose to shared it.
Attributes
Name | Type | Encrypted | Description |
---|---|---|---|
_id |
BSON::ObjectId | - | |
admin_password |
String | Yes | The password that grants access to the backend of the webshop . |
admin_url |
String | Yes | The URL where the backend of the webshop can be accessed. |
admin_username |
String | Yes | The username that grants access to the backend of the webshop . |
auth_id |
BSON::ObjectId | - | |
author_id |
String | No | |
closed_at |
Time | - | Timestamp that represents the time where the ticket was closed. |
comments |
String | Yes | Comments from the person who opened the ticket . |
company_id |
BSON::ObjectId | - | |
email |
String | Yes | The email of the person who opened the ticket . |
escalated_at |
Time | - | |
ftp_host |
String | Yes | The address of the webshop 's FTP server. E.g. 'ftp.example.com' . |
ftp_password |
String | Yes | The password that grants access to the FTP of the webshop . |
ftp_username |
String | Yes | The username that grants access to the FTP of the webshop . |
log |
Array | No | |
opened_at |
Time | - | Timestamp that represents the time where the ticket was opened. |
phone |
String | Yes | The phone number of the person who opened the ticket . |
relay_id |
BSON::ObjectId | - | |
ssh_address |
String | Yes | The IP address where you can reach the webshop 's server by SSH. E.g. 'ssh example@000.000.000.00' . |
ssh_password |
String | Yes | The password that grants access to the webshop 's server through SSH, only if password protection is being used to secure the connection. |
status |
String | No | A ticket can have the status 'open' , 'in_progress' or 'closed' . |
token |
String | No | |
updated_at |
Time | - | |
webshop_id |
BSON::ObjectId | - |
Indexes
Key | Name | Unique | Sparse |
---|---|---|---|
{"auth_id":1} |
No | No | |
{"company_id":1} |
No | No | |
{"relay_id":1,"status":1,"updated_at":-1} |
No | No | |
{"status":1,"webshop_id":1} |
No | No | |
{"superuser_id":1,"status":1,"updated_at":-1} |
No | No | |
{"webshop_id":1} |
No | No | |
{"webshop_id":1,"superuser_id":1,"status":1} |
No | No |
Description
A product
should not be considered a physical object that you can buy. Instead products
have variants
for that purpose. Even if the real life item don't really have variations the product
will still have a variant
.
The product
is used to store the informations that its variants
have in common, but the variant
is what will have changing availablility throughout its life cycle.
Attributes
Name | Type | Encrypted | Description |
---|---|---|---|
_id |
BSON::ObjectId | - | |
allow_backorders |
Boolean | - | Either true or false . |
barcode |
String | Yes | The barcode of the physical item in EAN, UPC or GTIN format, e.g. '570123456789' . |
before_price |
Float | - | The before price incl. all taxes, e.g. 399.99 or null . |
campaign |
String | Yes | The name of a campaign the the product is assigned to, e.g. 'arrivals' . |
campaign_finished_at |
Time | - | The time of a campaign to finish, e.g. '2023-02-28T23:59:59+01:00' . |
campaign_started_at |
Time | - | The time of a campaign to start, e.g. '2022-07-31T23:59:59+02:00' . |
category_ids |
Array | No | BSON::ObjectId's of the categories the product belongs to. |
company_id |
BSON::ObjectId | - | |
cost_price |
Float | - | The cost price excl. all taxes, e.g. 99.99 or null . |
currency |
String | No | E.g. 'USD' or '840' . This field don't follow any particular standards. |
description_1 |
String | Yes | E.g. '<p>Sporty Golong shoes in XL</p>' . |
description_2 |
String | Yes | E.g. '<p>The hottest Golong shoes from our XL collection</p>' . |
description_3 |
String | Yes | E.g. '<ul><li>Material: Leather</li><li>Size: XL</li></ul>' . |
height |
Integer | - | E.g. 20 . |
images |
Array | Yes | E.g. [{'remote_id': '1234-1-xl', 'url': 'https://example.com/images/1234-1-xl.png', 'title': 'Golong shoes', 'position': 1}] . It's depends on the ecommerce platform if it's possible to present the url's with domain and with https:// and www.. |
in_stock_message |
String | No | E.g. 'In stock' . |
length |
Integer | - | E.g. 30 . |
locations |
Hash | No | |
low_stock_limit |
Integer | - | E.g. 1 . |
manage_stock |
Boolean | - | Either true or false . |
manufacturer |
String | Yes | The producer or brand owner of the product. |
max_quantity |
Integer | - | The maximum quantity allowed for each purchase, e.g. 999 . |
meta_description |
String | Yes | E.g. 'Buy the hottest Golong shoes in XL' . |
meta_title |
String | Yes | E.g. 'Buy Golong shoes in XL' . |
min_quantity |
Integer | - | The minimum quantity allowed for each purchase, e.g. 1 . |
name |
String | Yes | E.g. 'Golong Shoes' . |
no_stock_message |
String | No | E.g. 'Not in stock' . |
offer_finished_at |
Time | - | The time of an offer to finish, e.g. '2023-02-28T23:59:59+01:00' . |
offer_price |
Float | - | The offer price incl. all taxes, e.g. 149.99 or null . |
offer_started_at |
Time | - | The time of an offer to start, e.g. '2022-07-31T23:59:59+02:00' . |
path |
String | Yes | E.g. 'golong-shoes' . |
price |
Float | - | The price incl. all taxes, e.g. 299.99 . |
product_id |
BSON::ObjectId | - | |
product_sku |
String | Yes | The same value as is stored in the sku field of the product it belongs to. A situation could occur where the product doesn not exist. |
published |
Boolean | - | Either true or false . |
published_scope |
String | No | The scope of the product, e.g. 'web' or global``. |
searchable |
String | No | Either true or false . |
size_unit |
String | No | E.g. 'cm' . |
sku |
String | Yes | A unique id of the variant that is used externally, e.g. '1234-XS' . |
sku_2 |
String | Yes | An internal ID used by the shop. |
sku_3 |
String | Yes | An internal ID used by the shop. |
status |
String | No | E.g. 'active' . |
stock |
Integer | - | E.g. -1 , 0 or 1 . It could also be null if the ecommerce platform don't support stock counts or if it is a non-physical item. |
stock_message_id |
BSON::ObjectId | - | |
stock_movements |
Array | No | An array with historical data about the availability of the variant over time. Example: [{'updated_at': ISODate('2020-12-31T11:59:59.929Z'), 'stock': 1, 'stock_message_id': null}] |
tags |
Array | Yes | E.g. ['shoes', 'xl'] . |
template |
String | Yes | E.g. 'shoes' . |
type |
String | No | E.g. 'advanced' |
unboxed_height |
Integer | - | E.g. 15 . |
unboxed_length |
Integer | - | E.g. 25 . |
unboxed_weight |
Integer | - | E.g. 600 . |
unboxed_width |
Integer | - | E.g. 15 . |
updated_at |
Time | - | |
url |
String | Yes | E.g. 'https://example.com/products/1234' . It depends on the ecommerce platform if it is possible to present the url with domain. |
variations |
Array | Yes | E.g. [{type: 'size', value: 'XS'}] or [] . |
vat_class |
String | No | The VAT settings of the product, e.g. 'default' . |
vat_pct |
Float | - | The VAT pct of the product, e.g. 0.25 . |
webshop_id |
BSON::ObjectId | - | |
weight |
Integer | - | E.g. 1000 . |
weight_unit |
String | No | E.g. 'g' . |
width |
Integer | - | E.g. 20 . |
Indexes
Key | Name | Unique | Sparse |
---|---|---|---|
{"webshop_id":1,"sku":1} |
Yes | No | |
{"webshop_id":1} |
No | No |
Description
webshops
belongs to companies
, and most documents belongs to both a company
and a webshop
.
A webshop
has a lot of fields that are maintained by Gofetch, and while you are free to inspect these you are probably never going to modify any other fields than active
.
Attributes
Name | Type | Encrypted | Description |
---|---|---|---|
_id |
BSON::ObjectId | - | |
active |
Boolean | - | Determines if we should schedule the webshop for fetching data. |
base_webshop_id |
BSON::ObjectId | - | |
cancelled_status_ids |
Array | No | |
categories_error |
Array | No | |
categories_stats |
Hash | No | |
closed_status_ids |
Array | No | |
company_id |
BSON::ObjectId | - | |
config |
Hash | No | |
created_categories_at |
Time | - | |
created_customers_at |
Time | - | |
created_orders_at |
Time | - | |
created_products_at |
Time | - | |
created_statuses_at |
Time | - | |
customers_error |
Array | No | |
customers_stats |
Hash | No | |
get_categories_created_since_catch_all_date |
Boolean | - | |
get_categories_created_since_last_request |
Boolean | - | |
get_categories_updated_since_catch_all_date |
Boolean | - | |
get_categories_updated_since_last_request |
Boolean | - | |
get_customers_created_since_catch_all_date |
Boolean | - | |
get_customers_created_since_last_request |
Boolean | - | |
get_customers_updated_since_catch_all_date |
Boolean | - | |
get_customers_updated_since_last_request |
Boolean | - | |
get_orders_created_since_catch_all_date |
Boolean | - | |
get_orders_created_since_last_request |
Boolean | - | |
get_orders_open_since_1x |
Boolean | - | |
get_orders_open_since_2x |
Boolean | - | |
get_orders_open_since_3x |
Boolean | - | |
get_orders_open_since_4x |
Boolean | - | |
get_orders_updated_since_catch_all_date |
Boolean | - | |
get_orders_updated_since_last_request |
Boolean | - | |
get_products_created_since_catch_all_date |
Boolean | - | |
get_products_created_since_last_request |
Boolean | - | |
get_products_updated_since_catch_all_date |
Boolean | - | |
get_products_updated_since_last_request |
Boolean | - | |
get_statuses_created_since_catch_all_date |
Boolean | - | |
get_statuses_created_since_last_request |
Boolean | - | |
get_statuses_updated_since_catch_all_date |
Boolean | - | |
get_statuses_updated_since_last_request |
Boolean | - | |
got_categories_created_since_catch_all_date_at |
Time | - | |
got_categories_created_since_last_request_at |
Time | - | |
got_categories_updated_since_catch_all_date_at |
Time | - | |
got_categories_updated_since_last_request_at |
Time | - | |
got_customers_created_since_catch_all_date_at |
Time | - | |
got_customers_created_since_last_request_at |
Time | - | |
got_customers_updated_since_catch_all_date_at |
Time | - | |
got_customers_updated_since_last_request_at |
Time | - | |
got_error_at |
Time | - | |
got_error_since |
Time | - | |
got_finished_at |
Time | - | |
got_orders_created_since_catch_all_date_at |
Time | - | |
got_orders_created_since_last_request_at |
Time | - | |
got_orders_open_since_1x_at |
Time | - | |
got_orders_open_since_2x_at |
Time | - | |
got_orders_open_since_3x_at |
Time | - | |
got_orders_open_since_4x_at |
Time | - | |
got_orders_updated_since_catch_all_date_at |
Time | - | |
got_orders_updated_since_last_request_at |
Time | - | |
got_products_created_since_catch_all_date_at |
Time | - | |
got_products_created_since_last_request_at |
Time | - | |
got_products_updated_since_catch_all_date_at |
Time | - | |
got_products_updated_since_last_request_at |
Time | - | |
got_started_at |
Time | - | |
got_statuses_created_since_catch_all_date_at |
Time | - | |
got_statuses_created_since_last_request_at |
Time | - | |
got_statuses_updated_since_catch_all_date_at |
Time | - | |
got_statuses_updated_since_last_request_at |
Time | - | |
ignore_status_ids |
Array | No | |
log |
Hash | No | |
logging |
Boolean | - | |
orders_error |
Array | No | |
orders_stats |
Hash | No | |
pending_status_ids |
Array | No | |
products_error |
Array | No | |
products_stats |
Hash | No | |
refunded_status_ids |
Array | No | |
relay_id |
BSON::ObjectId | - | |
shipped_status_ids |
Array | No | |
status |
String | No | |
statuses_error |
Array | No | |
statuses_stats |
Hash | No | |
updated_categories_at |
Time | - | |
updated_customers_at |
Time | - | |
updated_orders_at |
Time | - | |
updated_products_at |
Time | - | |
updated_statuses_at |
Time | - | |
webhook_token |
String | Yes |
Indexes
Key | Name | Unique | Sparse |
---|---|---|---|
{"_id":1,"company_id":1} |
No | No | |
{"active":1} |
No | No | |
{"active":1,"got_error_at":1,"relay_id":1} |
No | No | |
{"active":1,"got_error_since":1} |
No | No | |
{"active":1,"relay_id":1,"get_orders_created_since_catch_all_date":1,"got_orders_created_since_catch_all_date_at":1,"got_started_at":1} |
got_orders_created_since_catch_all_date_at_and_got_started_at | No | No |
{"active":1,"relay_id":1,"get_orders_created_since_catch_all_date":1,"got_started_at":1,"got_orders_created_since_catch_all_date_at":1} |
got_started_at_and_got_orders_created_since_catch_all_date_at | No | No |
{"active":1,"relay_id":1,"get_orders_created_since_last_request":1,"got_started_at":1,"got_orders_created_since_last_request_at":1} |
got_started_at_and_got_orders_created_since_last_request_at | No | No |
{"active":1,"relay_id":1,"get_orders_created_since_last_request":1,"got_orders_created_since_last_request_at":1,"got_started_at":1} |
got_orders_created_since_last_request_at_and_got_started_at | No | No |
{"active":1,"relay_id":1,"get_orders_open_since_1x":1,"got_started_at":1,"got_orders_open_since_1x_at":1} |
got_started_at_and_got_orders_open_since_1x_at | No | No |
{"active":1,"relay_id":1,"get_orders_open_since_2x":1,"got_started_at":1,"got_orders_open_since_2x_at":1} |
got_started_at_and_got_orders_open_since_2x_at | No | No |
{"active":1,"relay_id":1,"get_orders_open_since_3x":1,"got_started_at":1,"got_orders_open_since_3x_at":1} |
got_started_at_and_got_orders_open_since_3x_at | No | No |
{"active":1,"relay_id":1,"get_orders_open_since_4x":1,"got_started_at":1,"got_orders_open_since_4x_at":1} |
got_started_at_and_got_orders_open_since_4x_at | No | No |
{"active":1,"relay_id":1,"get_orders_open_since_1x":1,"got_orders_open_since_1x_at":1,"got_started_at":1} |
got_orders_open_since_1x_at_and_got_started_at | No | No |
{"active":1,"relay_id":1,"get_orders_open_since_2x":1,"got_orders_open_since_2x_at":1,"got_started_at":1} |
got_orders_open_since_2x_at_and_got_started_at | No | No |
{"active":1,"relay_id":1,"get_orders_open_since_3x":1,"got_orders_open_since_3x_at":1,"got_started_at":1} |
got_orders_open_since_3x_at_and_got_started_at | No | No |
{"active":1,"relay_id":1,"get_orders_open_since_4x":1,"got_orders_open_since_4x_at":1,"got_started_at":1} |
got_orders_open_since_4x_at_and_got_started_at | No | No |
{"active":1,"relay_id":1,"get_products_created_since_catch_all_date":1,"got_products_created_since_catch_all_date_at":1,"got_started_at":1} |
got_products_created_since_catch_all_date_at_and_got_started_at | No | No |
{"active":1,"relay_id":1,"get_products_created_since_catch_all_date":1,"got_started_at":1,"got_products_created_since_catch_all_date_at":1} |
got_started_at_and_got_products_created_since_catch_all_date_at | No | No |
{"active":1,"relay_id":1,"get_products_updated_since_catch_all_date":1,"got_products_updated_since_catch_all_date_at":1,"got_started_at":1} |
got_products_updated_since_catch_all_date_at_and_got_started_at | No | No |
{"active":1,"relay_id":1,"get_products_updated_since_catch_all_date":1,"got_started_at":1,"got_products_updated_since_catch_all_date_at":1} |
got_started_at_and_got_products_updated_since_catch_all_date_at | No | No |
{"active":1,"relay_id":1,"get_products_created_since_last_request":1,"got_started_at":1,"got_products_created_since_last_request_at":1} |
got_started_at_and_got_products_created_since_last_request_at | No | No |
{"active":1,"relay_id":1,"get_products_updated_since_last_request":1,"got_started_at":1,"got_products_updated_since_last_request_at":1} |
got_started_at_and_got_products_updated_since_last_request_at | No | No |
{"active":1,"relay_id":1,"get_products_created_since_last_request":1,"got_products_created_since_last_request_at":1,"got_started_at":1} |
got_products_created_since_last_request_at_and_got_started_at | No | No |
{"active":1,"relay_id":1,"get_products_updated_since_last_request":1,"got_products_updated_since_last_request_at":1,"got_started_at":1} |
got_products_updated_since_last_request_at_and_got_started_at | No | No |
{"active":1,"relay_id":1,"get_customers_created_since_catch_all_date":1,"got_customers_created_since_catch_all_date_at":1,"got_started_at":1} |
got_customers_created_since_catch_all_date_at_and_got_started_at | No | No |
{"active":1,"relay_id":1,"get_customers_created_since_catch_all_date":1,"got_started_at":1,"got_customers_created_since_catch_all_date_at":1} |
got_started_at_and_got_customers_created_since_catch_all_date_at | No | No |
{"active":1,"relay_id":1,"get_customers_updated_since_catch_all_date":1,"got_customers_updated_since_catch_all_date_at":1,"got_started_at":1} |
got_customers_updated_since_catch_all_date_at_and_got_started_at | No | No |
{"active":1,"relay_id":1,"get_customers_updated_since_catch_all_date":1,"got_started_at":1,"got_customers_updated_since_catch_all_date_at":1} |
got_started_at_and_got_customers_updated_since_catch_all_date_at | No | No |
{"active":1,"relay_id":1,"get_customers_created_since_last_request":1,"got_started_at":1,"got_customers_created_since_last_request_at":1} |
got_started_at_and_got_customers_created_since_last_request_at | No | No |
{"active":1,"relay_id":1,"get_customers_updated_since_last_request":1,"got_started_at":1,"got_customers_updated_since_last_request_at":1} |
got_started_at_and_got_customers_updated_since_last_request_at | No | No |
{"active":1,"relay_id":1,"get_customers_created_since_last_request":1,"got_customers_created_since_last_request_at":1,"got_started_at":1} |
got_customers_created_since_last_request_at_and_got_started_at | No | No |
{"active":1,"relay_id":1,"get_customers_updated_since_last_request":1,"got_customers_updated_since_last_request_at":1,"got_started_at":1} |
got_customers_updated_since_last_request_at_and_got_started_at | No | No |
{"active":1,"relay_id":1,"get_orders_updated_since_catch_all_date":1,"got_orders_updated_since_catch_all_date_at":1,"got_started_at":1} |
got_orders_updated_since_catch_all_date_at_and_got_started_at | No | No |
{"active":1,"relay_id":1,"get_orders_updated_since_catch_all_date":1,"got_started_at":1,"got_orders_updated_since_catch_all_date_at":1} |
got_started_at_and_got_orders_updated_since_catch_all_date_at | No | No |
{"active":1,"relay_id":1,"get_orders_updated_since_last_request":1,"got_started_at":1,"got_orders_updated_since_last_request_at":1} |
got_started_at_and_got_orders_updated_since_last_request_at | No | No |
{"active":1,"relay_id":1,"get_orders_updated_since_last_request":1,"got_orders_updated_since_last_request_at":1,"got_started_at":1} |
got_orders_updated_since_last_request_at_and_got_started_at | No | No |
{"active":1,"relay_id":1,"get_categories_created_since_catch_all_date":1,"got_categories_created_since_catch_all_date_at":1,"got_started_at":1} |
got_categories_created_since_catch_all_date_at_and_got_started_at | No | No |
{"active":1,"relay_id":1,"get_categories_created_since_catch_all_date":1,"got_started_at":1,"got_categories_created_since_catch_all_date_at":1} |
got_started_at_and_got_categories_created_since_catch_all_date_at | No | No |
{"active":1,"relay_id":1,"get_categories_updated_since_catch_all_date":1,"got_categories_updated_since_catch_all_date_at":1,"got_started_at":1} |
got_categories_updated_since_catch_all_date_at_and_got_started_at | No | No |
{"active":1,"relay_id":1,"get_categories_updated_since_catch_all_date":1,"got_started_at":1,"got_categories_updated_since_catch_all_date_at":1} |
got_started_at_and_got_categories_updated_since_catch_all_date_at | No | No |
{"active":1,"relay_id":1,"get_categories_created_since_last_request":1,"got_started_at":1,"got_categories_created_since_last_request_at":1} |
got_started_at_and_got_categories_created_since_last_request_at | No | No |
{"active":1,"relay_id":1,"get_categories_updated_since_last_request":1,"got_started_at":1,"got_categories_updated_since_last_request_at":1} |
got_started_at_and_got_categories_updated_since_last_request_at | No | No |
{"active":1,"relay_id":1,"get_categories_created_since_last_request":1,"got_categories_created_since_last_request_at":1,"got_started_at":1} |
got_categories_created_since_last_request_at_and_got_started_at | No | No |
{"active":1,"relay_id":1,"get_categories_updated_since_last_request":1,"got_categories_updated_since_last_request_at":1,"got_started_at":1} |
got_categories_updated_since_last_request_at_and_got_started_at | No | No |
{"active":1,"relay_id":1,"get_statuses_created_since_catch_all_date":1,"got_statuses_created_since_catch_all_date_at":1,"got_started_at":1} |
got_statuses_created_since_catch_all_date_at_and_got_started_at | No | No |
{"active":1,"relay_id":1,"get_statuses_created_since_catch_all_date":1,"got_started_at":1,"got_statuses_created_since_catch_all_date_at":1} |
got_started_at_and_got_statuses_created_since_catch_all_date_at | No | No |
{"company_id":1} |
No | No | |
{"relay_id":1,"webhook_token":1} |
Yes | No |
A shortcut is often the best and fastest way to configure an addon. Some shortcuts are used to integrate your addon subscriptions with each other. The following shortcuts require a subscription to this addon.
This API enables you to maintain your subscription programatically.
Each zone has its own API URL. Make sure to interact with the zone where your project belongs:
Zone | URL |
---|---|
European Union (EU) | https://gofetch-eu-api.goaddon.com |
United States (US) | https://gofetch-us-api.goaddon.com |
Thoughout these docs the URL of the European Union zone will be used.
All requests to the API must include a base64 encoded version of your Project API token .
If, for example, you want to update a project that has _id 5bf935bc3ab42fc4f4280d04
, and your API token is 2595f9cc-1a4f-44e7-a7ea-0b55029533ad
, then your request should look like this:
PATCH /project_api/v1/projects/5bf935bc3ab42fc4f4280d04 Host: https://gofetch-eu-api.goaddon.com Content-Type: application/json Accept: application/json Authorization: Basic MjU5NWY5Y2MtMWE0Zi00NGU3LWE3ZWEtMGI1NTAyOTUzM2Fk { "foo": "bar" }
Unauthorized requests will be responded with 401 Unauthorized
.
If you have subscribed with your project you can manage some of settings through this API.
Name | Type | Description |
---|---|---|
|
BSON::ObjectId |
|
|
Array |
Our interface is translated into different languages. If you are missing a language please contact us. To enable a language you need to include it in your array of allowed languages, e.g. Each time a user wants to access the interface you can pass his preferred language during session forwarding, or if you don't we will choose the first language from your array. |
|
String |
|
|
Integer |
You can set a limit on the number of shop syncronizations that can run simultaneously. If set to |
|
Boolean |
Determine whether unauthenticated visitors should be limited to view-only interface access. |
|
Boolean |
Determine whether unauthenticated visitors should be required to authenticate themselves before approving an integration. |
|
Boolean |
Determine whether unauthenticated should submit an email address when approving their first integration. |
|
Hash |
Whenever a user updates a shop through our interface we will display a confirmation message of your choosing. Example: { "en": "The integration has been updated." } |
|
String |
When users visits your website the script that you have inserted into your HTML code will contact our server in order to render our interface. We aim to stay in the background, so we would like to render it via your domain instead of ours. Pick a subdomain that you don't plan on using for other purposes, and point it to our servers. If you own |
|
String |
URL of your app where our interface should be displayed, e.g. |
|
String |
|
|
String |
When displaying the interface to your users we can include CSS classes of your choosing for certain elements. Here you can register classes for headlines, e.g. |
|
String |
When displaying the interface to your users we can include CSS classes of your choosing for certain elements. Here you can register classes for integration flags, e.g. |
|
String |
When displaying the interface to your users we can include CSS classes of your choosing for certain elements. Here you can register classes for red integration flags, e.g. |
|
String |
When displaying the interface to your users we can include CSS classes of your choosing for certain elements. Here you can register classes for green integration flags, e.g. |
|
String |
When displaying the interface to your users we can include CSS classes of your choosing for certain elements. Here you can register classes for yellow integration flags, e.g. |
|
String |
When displaying the interface to your users we can include CSS classes of your choosing for certain elements. Here you can register classes for grey integration flags, e.g. |
|
String |
When displaying the interface to your users we can include CSS classes of your choosing for certain elements. Here you can register classes for the integrations container, e.g. |
|
String |
When displaying the interface to your users we can include CSS classes of your choosing for certain elements. Here you can register classes for the integration container, e.g. |
|
String |
When displaying the interface to your users we can include CSS classes of your choosing for certain elements. Here you can register classes for the search input in the integrations container, e.g. |
|
String |
When displaying the interface to your users we can include CSS classes of your choosing for certain elements. Here you can register classes for the text input fields, e.g. |
|
String |
When displaying the interface to your users we can include CSS classes of your choosing for certain elements. Here you can register classes for an input note, e.g. |
|
String |
When displaying the interface to your users we can include CSS classes of your choosing for certain elements. Here you can register classes for an error, e.g. |
|
String |
When displaying the interface to your users we can include CSS classes of your choosing for certain elements. Here you can register classes for the error summary, e.g. |
|
String |
When displaying the interface to your users we can include CSS classes of your choosing for certain elements. Here you can register classes for forms, e.g. |
|
String |
When displaying the interface to your users we can include CSS classes of your choosing for certain elements. Here you can register classes for ol's, e.g. |
|
String |
When displaying the interface to your users we can include CSS classes of your choosing for certain elements. Here you can register classes for ul's, e.g. |
|
String |
When displaying the interface to your users we can include CSS classes of your choosing for certain elements. Here you can register classes for li's, e.g. |
|
String |
When displaying the interface to your users we can include CSS classes of your choosing for certain elements. Here you can register classes for th's, e.g. |
|
String |
When displaying the interface to your users we can include CSS classes of your choosing for certain elements. Here you can register classes for td's, e.g. |
|
String |
When displaying the interface to your users we can include CSS classes of your choosing for certain elements. Here you can register classes for checkboxes, e.g. |
|
String |
When displaying the interface to your users we can include CSS classes of your choosing for certain elements. Here you can register classes for radio buttons, e.g. |
|
String |
When displaying the interface to your users we can include CSS classes of your choosing for certain elements. Here you can register classes for labels, e.g. |
|
String |
When displaying the interface to your users we can include CSS classes of your choosing for certain elements. Here you can register classes for expand labels, e.g. |
|
String |
When displaying the interface to your users we can include CSS classes of your choosing for certain elements. Here you can register classes for identifiers, e.g. |
|
String |
When displaying the interface to your users we can include CSS classes of your choosing for certain elements. Here you can register classes for expanded containers, e.g. |
|
String |
When displaying the interface to your users we can include CSS classes of your choosing for certain elements. Here you can register classes for optoins containers, e.g. |
|
String |
When displaying the interface to your users we can include CSS classes of your choosing for certain elements. Here you can register classes for next buttons, e.g. |
|
String |
When displaying the interface to your users we can include CSS classes of your choosing for certain elements. Here you can register classes for next placeholder buttons, e.g. |
|
String |
When displaying the interface to your users we can include CSS classes of your choosing for certain elements. Here you can register classes for back buttons, e.g. |
|
String |
When displaying the interface to your users we can include CSS classes of your choosing for certain elements. Here you can register classes for back placeholder buttons, e.g. |
|
String |
When displaying the interface to your users we can include CSS classes of your choosing for certain elements. Here you can register classes for info buttons, e.g. |
|
String |
When displaying the interface to your users we can include CSS classes of your choosing for certain elements. Here you can register classes for tables, e.g. |
|
String |
When displaying the interface to your users we can include CSS classes of your choosing for certain elements. Here you can register classes for tables, e.g. |
|
String |
When displaying the interface to your users we can include CSS classes of your choosing for certain elements. Here you can register classes for links, e.g. |
|
String |
When displaying the interface to your users we can include CSS classes of your choosing for certain elements. Here you can register classes for messages, e.g. |
|
String |
When displaying the interface to your users we can include CSS classes of your choosing for certain elements. Here you can register classes for message links, e.g. |
|
String |
When an event occurs for one of the webshops in your Goaddon database we can trigger a webhook at your API in the form of a POST request. If you wish to receive such a webhook, please provide us with the recipient URL. You could e.g. choose |
|
String |
Path where our interface should be displayed. If our interface can e.g. be found at |
|
String |
Path where you want us to redirect users who just completed their integration. This would often be at |
|
String |
URL where users can sign up, e.g. If the destination is on the same domain or subdomain, you should only provide the path, e.g. |
|
String |
As described in our docs you need to implement session forwarding functionality to get our interface to display properly on your website. If you would like to receive session forwarding requests at e.g. |
|
String |
If you would like to receive a daily notification detailing which shops currently have issues with their integrations, you can submit the email address that should receive such notifications, e.g. |
|
String |
If you want to disable the merchants ability to submit support requests you should register a URL where the merchant can request support, e.g. |
|
String |
If you want to preserve the merchants ability to submit support requests, but you do not want the merchant to be able to communicate further with you through the Gofetch interface, you should register your support email address, e.g. |
|
String |
If you want to receive an email notification when a new support request is submitted, you should register an email address, e.g. |
|
String |
If you want to receive a POST request when a support request is created or updated with a new message from the merchant, you should register the URL, e.g. |
Updates your project
.
You can request basic details about a relay through this API.
Name | Type | Description |
---|---|---|
|
BSON::ObjectId |
|
|
String |
The name of the relay, e.g. |
|
String |
The author of the relay, e.g. |
|
String |
The unique identifier of the relay, e.g. |
|
Boolean |
Shows if the relay is currently active or inactive, which means that it relays data. |
|
Boolean |
Shows if the relay is currently active or published, which means new shops can sign up to get data relayed. |
|
Boolean |
Shows if the relay is an ecommerce platform that can create products and orders, or an integration that builds on top of ecommerce platforms (could for example be a payment provider or courier). |
|
Boolean |
Shows if the relay is an ecommerce platform that can be added to others (could for example be a payment provider or courier). |
|
Array |
The config keys that can be used to identify a webshop. |
|
Hash |
The requests that the relay currently accepts. |
|
Hash |
A representation of the Shop API resources and endpoints that are available for the relay. A very compressed example: { "v1": { "endpoints": { "orders": [ { "name": "index", "method": "get", "description": "Requests the shop for orders.", "url": "https://gofetch-api.example.com/shop_api/v1/orders", "params": [ { "key": "webshop_id", "description": "`_id` of `webshop` document in your database. Your request will be submitted to this particular shop." }, { "key": "created_since", "description": "The orders should have been created since the timestamp, in ISO 8601 format: `2020-12-31T23:59:59+01:00`." } ] }, { "name": "create_shipment", "method": "patch", "description": "Requests the shop to create a shipment for the order.", "url": "https://gofetch-api.example.com/shop_api/v1/orders/{{ order_id }}/create_shipment", "params": [ ], "body_description": { "data": { "tracking_number": "Tracking number of the shipment, e.g. `ABC123456789`." } }, "body_example": { "data": { "tracking_number": "ABC123456789" } }, "comments": "Please note that for this specific ecommerce platform there are the following limitations...", "templates": [ { "title": "Trimmed", "body": { "data": { "status_id": "shipped" } } } ] } ] } } } |
|
String |
A description of the current fees for support offered by the relay, e.g. |
|
String |
The path that is used to authenticate and initiate new integrations, e.g. |
Get relays.
Get a specific relay.
This API enables you to interact with the shops that you are integrated with. You should communicate with the API through the domain or subdomain that you have assigned to Gofetch , exemplified throughout this API reference with gofetch-api.example.com.
Your API requests are forwarded to the relay that is responsible for the integration. The relay will then attempt to perform the requested action in the integrated shop. You can read the result of this attempt in the response.
Your own Goaddon database will not be modified by requests to this API, all though your actions should be reflected in the data you subsequently get from the shop.
The Shop API is best utilized in combination with your Goaddon database. When you perform state changing requests (POST, PATCH and DELETE) you have the option to reference documents from your database. If, for example, you want to update a product, you can provide the _id
of the product
document from your database as the id in the request path:
PATCH /shop_api/v1/products/5bf935bc3ab42fc4f4280d04
The Shop API will do the rest of the work by connecting to the shop that the product belongs to. The Shop API will also sort out the informations needed in order for the shop to be able to identify the product.
If you would rather want to do the heavy lifting yourself you can provide a bypass_db
param with the value true
. Or you can provide it as a key in the root of requests that allows for a request body. In that case it will vary what informations you should provide in order for the shop to identify what you are requesting about. A product, for example, would most often be identified by its sku
, while an order most often by its order_number
. You would also need to provide the _id
to the webshop
you want to interact with:
PATCH /shop_api/v1/products/1234?bypass_db=true&webshop_id=610f626e3ab42f0c1f361fc1
Please note that not all relays are able to support all actions documented here, and the actions taken based on the same request will vary with the platform. Even if a request is supported you should not expect that its response contains all the informations described below. Therefore, if your app is communicating with shops from different ecommerce platforms you would need to adjust your strategy to the individual ecommerce platform. A webshop
document has a relay_id
attribute, which will never change. Design your strategies based on these.
The best way to experiment with this API is through our Goexplore enabled repository gofetch-goexplore-a-superuser-tools .
All requests to the API must include a base64 encoded version of your Shop API token .
If, for example, you want to update a variant that has _id 5bf935bc3ab42fc4f4280d04
, and your API token is 2595f9cc-1a4f-44e7-a7ea-0b55029533ad
, then your request should look like this:
PATCH /shop_api/v1/variants/5bf935bc3ab42fc4f4280d04 Host: https://gofetch-api.example.com Content-Type: application/json Accept: application/json Authorization: Basic MjU5NWY5Y2MtMWE0Zi00NGU3LWE3ZWEtMGI1NTAyOTUzM2Fk { "foo": "bar" }
Unauthorized requests will be responded with 401 Unauthorized
.
A category belongs to a webshop
.
Requests the shop for all product categories.
The request will not change anything in the shop.
Requests the shop to create a category.
Since you are creating a new category you would need to pass a webshop_id
as a param in order to let the Shop API know where to create the category. You can also pass it in the root of the payload.
Requests the shop to update a category.
The {{ category_id }}
in the request path refers to the _id
from the category
document in your Goaddon database, unless you are using the bypass_db
option, in which case you should provide the remote_id
of the category, depending on the individual integration.
If you include a webshop_id
param in the request URL, the Shop API will check if the category belongs to the webshop you expect it to. If you are using the bypass_db
option you must provide a webshop_id
, but no checks will be carried out.
Requests the shop to delete a category.
If you include a webshop_id
param in the request URL, the Shop API will check if the category belongs to the webshop you expect it to. If you are using the bypass_db
option you must provide a webshop_id
, but no checks will be carried out.
A country belongs to a webshop
.
Requests the shop for all countries.
The request will not change anything in the shop.
A customer belongs to a webshop
, and has many orders
.
Requests the shop for all customers.
The request will not change anything in the shop.
Requests the shop to create a customer.
Since you are creating a new customer you would need to pass a webshop_id
as a param in order to let the Shop API know where to create the customer. You can also pass it in the root of the payload.
Requests the shop to update a customer.
The {{ customer_id }}
in the request path refers to the _id
from the customer
document in your Goaddon database, unless you are using the bypass_db
option, in which case you should provide the remote_id
of the customer, depending on the individual integration.
If you include a webshop_id
param in the request URL, the Shop API will check if the customer belongs to the webshop you expect it to. If you are using the bypass_db
option you must provide a webshop_id
, but no checks will be carried out.
Requests the shop to delete a customer.
If you include a webshop_id
param in the request URL, the Shop API will check if the customer belongs to the webshop you expect it to. If you are using the bypass_db
option you must provide a webshop_id
, but no checks will be carried out.
A delivery method belongs to a webshop
.
Requests the shop for all delivery methods.
The request will not change anything in the shop.
An order line belongs to a webshop
and an order
.
Requests the shop to update an order line.
The {{ order_line_id }}
in the request path refers to the _id
from the order_line
document in your Goaddon database, unless you are using the bypass_db
option, in which case you should provide the remote_id
of the order line, depending on the individual integration.
If you include a webshop_id
param in the request URL, the Shop API will check if the order line belongs to the webshop you expect it to. If you are using the bypass_db
option you must provide a webshop_id
, but no checks will be carried out.
Requests the shop to delete a order line.
If you include a webshop_id
param in the request URL, the Shop API will check if the order line belongs to the webshop you expect it to. If you are using the bypass_db
option you must provide a webshop_id
, but no checks will be carried out.
An order is unique by its order_number
, and belongs to a company
and a webshop
.
Requests the shop for orders that meets criterias provided in the request params.
The request will not change anything in the shop, and is mostly usefull for debugging purposes.
Requests the shop to create an order.
Since you are creating a new order you would need to pass a webshop_id
as a param in order to let the Shop API know where to create the order. You can also pass it in the root of the payload.
A number of document _id
s can be provided to create an association to the order. The _id
inside the customer
attribute refers to an _id
of a customer in your Goaddon database. The _id
s of the billing_country
and shipping_country
attributes refer to country
documents. The payment_method
and delivery_method
attributes refer to payment_method
and delivery_method
documents. The status
refers to the status
document that represents the status of the order. And within the variants
array, the _id
refers to the variant
document that should be the basis of an order line.
You need to include a webshop_id
param in the request URL, so the Shop API can target the relevant shop with the request. The Shop API will also check if the associated documents belong to the webshop you expect it to.
If you are using the bypass_db
option you should not provide _id
s inside the billing_country
, shipping_country
, payment_method
and payment_method
attributes. Instead you need to provide the attributes recognized by the shop. Typically these should be titled remote_id
, but it varies with the individual integration. In the variants
array you would typically need to provide the sku
, sku_2
or sku_3
of the variant, depending on the individual integration.
You can mix the two approaches in the same payload as you please, and since no documents are required in order to make this request the bypass_db
option doesn't give a different result from just leaving out all _id
attributes.
Requests the shop to update an order.
Requests the shop to delete an order.
Requests the shop to close or archive the order. This is typically done upon having shipped everything and captured any payment card transactions associated with the order.
If you include the _id
of a status
, the shop will be requested to move the order into that particular status, though not all ecommerce platforms are able to support this. You may be able to check the available statuses through the statuses endpoint.
While for some ecommerce platforms this action simply moves the order from one filter to another, others will perform use it to finalize open orders as per their internal logic. Some will automatically capture any payment card transaction associated with the order, but for others this is optional or even impossible. To the extend that it is possible you can provide instructions with the capture
and capture_amount
keys.
Using this endpoint could affect the state
property of the order in your Goaddon database next time you synchronize with the shop. It could also result in the status_id
being updated.
This endpoint should only close the order, but not have any affect on shipments
. However the precise behaviour of the shop, and the subsequent syncronization with your Goaddon database, depends on the specific ecommerce platform. A closely related method is the create_shipment endpoint, which for some ecommerce platforms creates shipments without closing the order, or create shipments and simultaneously closes the order.
The {{ order_id }}
in the request path refers to the _id
from the order
document in your Goaddon database, unless you are using the bypass_db
option, in which case you should provide the order_number
or remote_id
, depending on the individual integration.
If you include a webshop_id
param in the request URL, the Shop API will check if the order belongs to the webshop you expect it to. If you are using the bypass_db
option you must provide a webshop_id
, but no checks will be carried out.
Requests the shop to create a shipment for the order.
This should result in a new shipment
being created in your Goaddon database next time you synchronize with the shop. It could also affect the state
property of the order, and it could result in the status_id
of the order to be updated in your Goaddon database.
Since some ecommerce platforms can not create a shipment without also closing the order and/or capturing any payment card transaction associated with the order, you can include a capture
and capture_amount
key. These keys are described on the create_shipment endpoint.
The {{ order_id }}
in the request path refers to the _id
from the order
document in your Goaddon database, unless you are using the bypass_db
option, in which case you should provide the order_number
or remote_id
, depending on the individual integration.
If you include an array of order_lines
the shop will be requested to connect the shipment to these specific order lines. An order line is also referenced by its document _id
in your Goaddon database, unless you are using the bypass_db
option, in which case you should provide a variant_sku
attribute that contains the identifier needed for the shop to identify the order line. If you include an empty array, or no array at all, the shop will most likely assume that the shipment should include all order lines. Not all ecommerce platforms are able to connect order lines to shipments.
You can optionally include tracking_number
and courier
. If you include the _id
of a status
the shop will be requested to move the order into that particular status (you may be able to check the available statuses through the statuses endpoint), but not all ecommerce platforms are able to register these informations.
If you include a webshop_id
param in the request URL, the Shop API will check if the order belongs to the webshop you expect it to. If you are using the bypass_db
option you must provide a webshop_id
, but no checks will be carried out.
Requests the shop to create an invoice for the order.
It will vary a lot how this would affect the order that is syncronized with your Goaddon database. It could also the state
property of the order, and it could result in the status_id
of the order to be updated in your Goaddon database.
The {{ order_id }}
in the request path refers to the _id
from the order
document in your Goaddon database, unless you are using the bypass_db
option, in which case you should provide the order_number
or remote_id
, depending on the individual integration.
If you include an array of order_lines
the shop will be requested to connect the shipment to these specific order lines. An order line is also referenced by its document _id
in your Goaddon database, unless you are using the bypass_db
option, in which case you should provide a variant_sku
attribute that contains the identifier needed for the shop to identify the order line. If you include an empty array, or no array at all, the shop will most likely assume that the invoice should include all order lines. You may also be able to provide include_shipping
, include_payment
and include_discount
attributes, which can either be true
or false
, to signal whether to include the shipping and payment price and discount amount in the invoice. Different ecommerce platforms may have different policies, like for example enforcing their inclusion on the last invoice. Not all ecommerce platforms are able to connect order lines to invoices.
If you include a webshop_id
param in the request URL, the Shop API will check if the order belongs to the webshop you expect it to. If you are using the bypass_db
option you must provide a webshop_id
, but no checks will be carried out.
If you include the _id
of a status
the shop will be requested to move the order into that particular status (you may be able to check the available statuses through the statuses endpoint), but not all ecommerce platforms are able to register these informations.
If the ecommerce platform does not calculate the invoice amount based on the provided order lines you may be able to specify an invoice_amount
, e.g. 100.99
. You may also be able to capture the payment card transaction associated with the order by including a capture
key, but since you can already specify an amount to invoice, you can not also specify the amount to capture.
Many ecommerce platforms will not be compatible with this endpoint.
Requests the shop to capture the card payment of an order.
You can include a capture_amount
in the data, e.g. 100.99
, which some ecommerce platforms support, or an invoice_id
, which others do.
If you include the _id
of a status
the shop will be requested to move the order into that particular status (you may be able to check the available statuses through the statuses endpoint), but not all ecommerce platforms are able to register these informations.
The {{ order_id }}
in the request path refers to the _id
from the order
document in your Goaddon database, unless you are using the bypass_db
option, in which case you should provide the order_number
or remote_id
, depending on the individual integration.
If you include a webshop_id
param in the request URL, the Shop API will check if the order belongs to the webshop you expect it to. If you are using the bypass_db
option you must provide a webshop_id
, but no checks will be carried out.
Requests the shop to refund the card payment of an order.
The {{ order_id }}
in the request path refers to the _id
from the order
document in your Goaddon database, unless you are using the bypass_db
option, in which case you should provide the order_number
or remote_id
, depending on the individual integration.
If you include the _id
of a status
the shop will be requested to move the order into that particular status (you may be able to check the available statuses through the statuses endpoint), but not all ecommerce platforms are able to register these informations.
If you include a webshop_id
param in the request URL, the Shop API will check if the order belongs to the webshop you expect it to. If you are using the bypass_db
option you must provide a webshop_id
, but no checks will be carried out.
You can include a refund_amount
in the data, e.g. 100.99
, which some ecommerce platforms support, or a credit_note_id
, which others do.
Requests the shop to register that a previously closed order has been returned.
The {{ order_id }}
in the request path refers to the _id
from the order
document in your Goaddon database, unless you are using the bypass_db
option, in which case you should provide the order_number
or remote_id
, depending on the individual integration.
If you include an array of order_lines
the shop will be requested to only register the return of these specific order lines. An order line is also referenced by its document _id
in your Goaddon database, unless you are using the bypass_db
option, in which case you should provide a variant_sku
attribute that contains the identifier needed for the shop to identify the order line. If you include an empty array, or no array at all, the shop will most likely assume that all order lines are returned. Not all ecommerce platforms are able to associate a specific return with specific order lines. You may be able to provide include_shipping
, include_payment
and include_discount
in the credit note, if a credit note is generated based on the action, to specify whether the transaction cost and discount associated with the order should be included in the credit note.
If you include a webshop_id
param in the request URL, the Shop API will check if the order belongs to the webshop you expect it to. If you are using the bypass_db
option you must provide a webshop_id
, but no checks will be carried out.
If you include the _id
of a status
, the shop will be requested to move the order into that particular status, though not all ecommerce platforms are able to support this. You can include a refund
key, either true
or false
, and optionally also a refund_amount
, e.g. 100.99
. If the ecommerce platform supports this, it will attempt to issue the refund.
If you include a restock
key with the value true
the shop will be instructed to put the ordered order lines back in stock, though not all ecommerce platforms are able to support this.
Requests the shop to update the status of an order.
The {{ order_id }}
in the request path refers to the _id
from the order
document in your Goaddon database, unless you are using the bypass_db
option, in which case you should provide the order_number
or remote_id
, depending on the individual integration.
If you include a webshop_id
param in the request URL, the Shop API will check if the order belongs to the webshop you expect it to. If you are using the bypass_db
option you must provide a webshop_id
, but no checks will be carried out.
If you include the _id
of a status
, the shop will be requested to move the order into that particular status, though not all ecommerce platforms are able to support this.
Requests the shop to cancel the order.
If you include the _id
of a status
, the shop will be requested to move the order into that particular status, though not all ecommerce platforms are able to support this. You may be able to check the available statuses through the statuses endpoint.
Some ecommerce platforms will automatically refund any payment card transaction previously captured for the associated order, but for others this is optional or even impossible. To the extend that it is possible you can provide instructions with the refund
and refund_amount
keys. Be careful not to unintentionally issue refunds.
This should affect the state
property of the order in your Goaddon database next time you synchronize with the shop. It could also result in the status_id
being updated.
The {{ order_id }}
in the request path refers to the _id
from the order
document in your Goaddon database, unless you are using the bypass_db
option, in which case you should provide the order_number
or remote_id
, depending on the individual integration.
If you include a webshop_id
param in the request URL, the Shop API will check if the order belongs to the webshop you expect it to. If you are using the bypass_db
option you must provide a webshop_id
, but no checks will be carried out.
Requests the shop to add an order line to an order.
This should result in a new order_line
being created in your Goaddon database next time you synchronize with the shop.
The {{ order_id }}
in the request path refers to the _id
from the order
document in your Goaddon database, unless you are using the bypass_db
option, in which case you should provide the order_number
or remote_id
, depending on the individual integration.
If you include a webshop_id
param in the request URL, the Shop API will check if the order belongs to the webshop you expect it to. If you are using the bypass_db
option you must provide a webshop_id
, but no checks will be carried out.
A payment method belongs to a webshop
.
Requests the shop for all payment methods.
The request will not change anything in the shop.
A product is unique by its sku
, and belongs to a company
and a webshop
.
Requests the shop for products or variants that meets criterias provided in the request params.
The request will not change anything in the shop, and is mostly usefull for debugging purposes.
Requests the shop to create a product and any number of variants of it.
Since you are creating a new product you would need to pass a webshop_id
as a param in order to let the Shop API know where to create the product. You can also pass it in the root of the payload.
It varies between ecommerce platforms how products and variants intersect with each other. Some assign most attributes to the product, and only assign its variants with its physical attributes, specifically stock
, in_stock_message
, no_stock_message
, barcode
and variations
. Others do not use the product as anything more than a shared reference that connects variants. For this reason the Shop API allows you you provide all attributes on both the product and variants
level, except the ones mentioned. Many ecommerce platforms will let you assign attributes that are shared between variants when provided on the product level, but check the additional comments for each integration.
Once you have created a product, it will have been created in as many versions as you have variants in your payload. Each of them will have been created with the attributes of the product combined with the attributes of the individual variant, as previously described. When subsequently transferred to your database they will be represented as many variant
documents and one shared product
document. In order to make updates you must target the variants rather than the product. Products without variations will only have a single variant with the same sku
as the product it belongs to.
Requests the shop to update a product.
The {{ product_id }}
in the request path refers to the _id
from the product
document in your Goaddon database, unless you are using the bypass_db
option, in which case you should provide the sku
, sku_2
or sku_3
of the product, depending on the individual integration.
If you include a webshop_id
param in the request URL, the Shop API will check if the product belongs to the webshop you expect it to. If you are using the bypass_db
option you must provide a webshop_id
, but no checks will be carried out.
Requests the shop to delete a product.
If you include a webshop_id
param in the request URL, the Shop API will check if the product belongs to the webshop you expect it to. If you are using the bypass_db
option you must provide a webshop_id
, but no checks will be carried out.
Requests the shop to create a variant of a product.
If you include a webshop_id
param in the request URL, the Shop API will check if the product belongs to the webshop you expect it to. If you are using the bypass_db
option you must provide a webshop_id
, but no checks will be carried out.
Requests the shop to create a add an image to a product.
If you include a webshop_id
param in the request URL, the Shop API will check if the product belongs to the webshop you expect it to. If you are using the bypass_db
option you must provide a webshop_id
, but no checks will be carried out.
Requests the shop to remove an image to a product.
If you include a webshop_id
param in the request URL, the Shop API will check if the product belongs to the webshop you expect it to. If you are using the bypass_db
option you must provide a webshop_id
, but no checks will be carried out.
A shipment belongs to a webshop
and an order
.
Requests the shop to update a shipment.
The {{ shipment_id }}
in the request path refers to the _id
from the shipment
document in your Goaddon database, unless you are using the bypass_db
option, in which case you should provide the remote_id
of the shipment, depending on the individual integration.
If you include a webshop_id
param in the request URL, the Shop API will check if the shipment belongs to the webshop you expect it to. If you are using the bypass_db
option you must provide a webshop_id
, but no checks will be carried out.
Requests the shop to delete a shipment.
If you include a webshop_id
param in the request URL, the Shop API will check if the shipment belongs to the webshop you expect it to. If you are using the bypass_db
option you must provide a webshop_id
, but no checks will be carried out.
A shop ID belongs to a webshop
. If multiple shop ID's exists the webshop
document has been assiciated with one of these through a shop_id
attribute inside the config
attribute.
Requests the shop for all known shop ids.
The request will not change anything in the shop.
A status belongs to a webshop
.
Requests the shop for all order statuses.
The request will not change anything in the shop.
Variants belongs to products. Even a product with no variations has a variant that contains properties like the stock count. When you wish to modify such properties you would need to identify the correct variant and perform the action on it.
Requests the shop to update a variant of a product.
The {{ variant_id }}
in the request path refers to the _id
from the variant
document in your Goaddon database, unless you are using the bypass_db
option, in which case you should provide the sku
, sku_2
or sku_3
of the variant, depending on the individual integration.
If you include a webshop_id
param in the request URL, the Shop API will check if the variant belongs to the webshop you expect it to. If you are using the bypass_db
option you must provide a webshop_id
, but no checks will be carried out.
Since ecommerce platforms have different definitions of products and variants it may be impossible to update products directly, but necessary to individually update the variants of a product instead. Therefore you can include all product attributes in the payload of variant updates.
Requests the shop to delete a variant of a product.
The {{ variant_id }}
in the request path refers to the _id
from the variant
document in your Goaddon database, unless you are using the bypass_db
option, in which case you should provide the sku
, sku_2
or sku_3
of the variant, depending on the individual integration.
Requests the shop to change the stock count of a variant, and/or the stock message associated with it.
If you provide a stock_change
, this request delegates to the shop to determine the resulting stock count by adding or substracting the number you specify as stock_change
. If, on the other hand, you provide a stock
the shop should overwrite the stock count completely. Do not include both keys. This should affect the stock
property of the variant in your Goaddon database next time you synchronize with the shop.
The {{ variant_id }}
in the request path refers to the _id
from the variant
document in your Goaddon database, unless you are using the bypass_db
option, in which case you should provide the sku
, sku_2
or sku_3
of the variant, depending on the individual integration.
If you include a webshop_id
param in the request URL, the Shop API will check if the variant belongs to the webshop you expect it to. If you are using the bypass_db
option you must provide a webshop_id
, but no checks will be carried out.
Requests the shop to create a add an image to a variant.
If you include a webshop_id
param in the request URL, the Shop API will check if the variant belongs to the webshop you expect it to. If you are using the bypass_db
option you must provide a webshop_id
, but no checks will be carried out.
Requests the shop to remove an image to a variant.
If you include a webshop_id
param in the request URL, the Shop API will check if the variant belongs to the webshop you expect it to. If you are using the bypass_db
option you must provide a webshop_id
, but no checks will be carried out.
A webshop is what most other documents belong to.
Requests the shop to update its general settings.
The possibilities offered through this endpoint depends on, and varies with, the specific ecommerce platform.
Gofetch enables you to exchange data with online shops from a wide selection of ecommerce platforms.
Currently the following ecommerce platforms are supported.
Platform | Author | Description |
---|---|---|
Centra | Goaddon | |
Consignor | Goaddon | |
DanDomain | Goaddon | |
DanDomain Classic | Goaddon | |
ePay | Goaddon | |
ideal.shop | Goaddon | This integration exposes a webhook API that a shop can query with to submit their product and order data. The API will be made available on a subdomain of yours. |
Magento v.1 | Goaddon | For this integration we will create a module that the shop owner needs to install in his shop. The module will relfect your brand details. |
Magento v.2 | Goaddon | For this integration we will create a module that the shop owner needs to install in his shop. The module will relfect your brand details. |
Norce | Goaddon | |
OpenBizBox | Goaddon | |
Prestashop | Goaddon | For this integration we will create a module that the shop owner needs to install in his shop. The module will relfect your brand details. |
Quickbutik | Goaddon | |
QuickPay | Goaddon | |
Salesforce Commerce Cloud | Goaddon | |
Salesforce Order Management | Goaddon | |
ScanNet | Goaddon | |
Shipmondo | Goaddon | |
Shopify | Goaddon | This integration requires you to create a developer account at Shopify . |
Shopify (custom app) | Goaddon | To enable the integration with Shopify shops you need to create a Shopify partner account and from within that account, create an app. Your app needs to be published in the Shopify app store in order to be operational outside the scope of your development store. |
ShopOrama | Goaddon | |
Smartweb | Goaddon | |
SumoShop | Goaddon | |
Wannafind | Goaddon | |
Webhook & API | Goaddon | This integration exposes a webhook API that a shop can query with to submit their product and order data. The API will be made available on a subdomain of yours. |
Wikinggruppen | Goaddon | |
WooCommerce | Goaddon | For this integration we will create a plugin that the shop owner needs to install in his shop. The plugin will relfect your brand details. |
While the current selection cover most of the popular ecommerce platforms you will undoubtedly be confronted with shops who you can't offer your services to. There is nothing more frustrating than turning down a potential customer, just because their data is inaccessible to you.
On the upside, your competitors will probably experience this more often than you. Because when subscribing to Gofetch you are tapping into the collective work of everybody who goes through the effort of integrating a new ecommerce platform. As time progress, the number of supported ecommerce platforms will grow.
If there is a specific ecommerce platform you just can't wait for, you can be the one to add support for it. This is called building a relay. And if you publish it for others to use, you can even make money on it.
You can set your own pricing policy, and if others find it fair they will subcribe to it.
We are working actively on a dedicated website where you can read instructions and submit your relay for review.