Por outro lado, se pretender obter a informação de um fornecedor específico, deverá realizar o mesmo pedido, especificando o id do fornecedor que deseja consultar
get
Path parameters
idintegerRequired
Responses
200
OK
No content
get
/suppliers/{id}
200
OK
No content
A seguinte rota permite a criação de novas instâncias de fornecedores. De modo a realizar um pedido para esta rota, terá de enviar alguns parâmetros no body do pedido.
Tal como está descrito no pedido em baixo, dentro do body terá de criar dois objetos: data, e relationships.
Dentro de data, deverá colocar todos os parâmetros obrigatórios (assinalados com um asterisco), e poderá também colocar os restantes parâmetros, se for do seu interesse. O tipo dos parâmetros está também especificado.
Dentro de relationships deverá colocar um objeto para cada uma das entradas descritas em baixo, sendo que cada uma deverá conter todos os parâmetros indicados.
post
Body
Responses
200
OK
application/json
post
/suppliers
200
OK
Em alternativa, temos descrito o cURL necessário para realizar este pedido:
Neste, o payload JSON deverá ser do seguinte formato
A seguinte rota permite a remoção de um dado fornecedor. Esta rota deve ser utilizada de forma cautelosa dado que é irreversível, e mesmo que este cliente volte a ser criado, o seu id nunca será o mesmo que teria anteriormente.
Utilizando o id do forncedor que quer eliminar, que poderá fazer utilizando a primeira rota desta página, por exemplo, terá simplesmente de fazer o pedido:
Este irá retornar OK em caso de sucesso.
delete
Path parameters
idintegerRequired
Responses
200
OK
No content
delete
/suppliers/{id}
200
OK
No content
A rota PATCH permite a edição de um fornecedor existente. O body deste pedido deverá ser igual ao descrito na rota POST, contendo todas as informações obrigatórias do fornecedor, atualizadas para os valores que tenciona alterar, além do "id" do fornecedor. Álem disto, o pedido deverá ser feito a https://apiv1.toconline.com/suppliers/{id}, sendo que {id} é o identificador do fornecedor que tenciona atualizar.
patch
Path parameters
idintegerRequired
Responses
200
OK
No content
patch
/suppliers/{id}
200
OK
No content
Neste, o PAYLOAD_JSON deverá ser do seguinte formato:
Morada
De modo a associar uma morada a um cliente, deverá realizar o seguinte pedido
patch
Body
Responses
200
OK
application/json
patch
/addresses
200
OK
No pedido acima, o <access_token> corresponde ao token de acesso válido devolvido pelo serviço de OAuth, e o <payload JSON> deverá ter o seguinte formato
NOTA 1: O "id" interno do país deve ser obtido por um GET /countries?filter[iso_alpha_2]=PT|<o código do país>... São também suportados dois "países" adicionais: "PT-AC" (Portugal, Açores) e "PT-MA" (Portugal, Madeira).
E-mail
De modo a associar um email a um cliente, deverá realizar o seguinte pedido
patch
Body
Responses
200
OK
application/json
patch
/email_addresses
200
OK
No pedido acima, o <access_token> corresponde ao token de acesso válido devolvido pelo serviço de OAuth, e o <payload JSON> deverá ter o seguinte formato
// Exemplo de payload
{
"data": {
"type": "addresses", // [OBRIGATÓRIO]
"id": "<id da morada principal do cliente>", // [OBRIGATÓRIO]
"attributes": {
"address_detail": "Test address", // [OPCIONAL]
"city": "Test city", // [OPCIONAL]
"postcode": "0000-000", // [OPCIONAL] Se o país for Portugal, deve obedecer ao formato português, DDDD-DDD
"region": "Test region" // [OPCIONAL]
},
"relationships": { // [OPCIONAL] Recursos associados à morada. Caso nenhum seja indicado, este bloco "relationships" deve ser omitido
"country": { // [OPCIONAL] Por omissão, a morada fica associada ao país "PT"
"data": {
"type": "countries", // [OBRIGATÓRIO]
"id": "<id do país>" // [OBRIGATÓRIO] Vd. NOTA 1
}
}
}
}
}
