Page Title: TINY API documentation

  • This webpage makes use of the TITLE meta tag - this is good for search engine optimization.

Page Description: API documentation

  • This webpage makes use of the DESCRIPTION meta tag - this is good for search engine optimization.

Page Keywords: Tiny, tinyurl, QR codes, url shortener, URL redirect, tinylink

  • This webpage makes use of the KEYWORDS meta tag - whilst search engines nowadays do not put too much emphasis on this meta tag including them in your website does no harm.

Page Text: This is v3 of TINYCC REST API. It conforms to the REST API concept . API root URL: https://tiny.cc/tiny/api/3/ HTTPs and HTTP supported. But HTTPs recommended. Authentication: HTTP Basic . Use your username:api-key for user:password. Example: johndoe:c2es9d56-045d-4d87-b3f2-419274f4e001 Please login to your account to manage api-key. If you have problem using PATCH HTTP method, we support method override for POST calls via X-HTTP-Method-Override header. Recommended encoding for request's payload - "application/json" . However "application/x-www-form-urlencoded" and "multipart/form-data" are also supported for POST requests. If you want to make PATCH (or other non POST) request with encoding other then "application/json", you should use POST method and set X-HTTP-Method-Override header. GET-parameters should be "percent-encoded" . Responses always encoded with "application/json". All date-time values in API are in UTC±00:00. Inactive accounts can't access API. They will get error 1217. Getting account info Input params: none Example response: { "error": { "code": 0, "message": "" }, "account": { "user_id": "4274", "username": "johndoe", "account_expiration_date": "2015-08-30 20:57:03", "subscription_plan": "Secure Plan (1 year)", "counters": { "urls": { "count": 13, "limit": 5000 }, "today_api_calls": { "count": 8, "limit": 500 }, "month_urls": { "count": 13, "limit": 500 } } } } Response contains information about different counters. These fields depend on server configuration and may vary from server to server. Shortening URLs POST /urls Input params: { "urls": [ { "custom_hash": "mytiny", "long_url": "http://example.com", "note": "lots of notes...", "email_stats": false, "expiration_date": "2016-01-02", "tags":["group1"] } ] } All fields are optional except "long_url". Default values: "custom_hash" - autogenerated "favorite" - false "no_stats" - true Maximum length of "long_url" limited to 2048. Maximum length of "custom_hash" limited to 25. "note" always trimmed to 25 characters. Example of successful response: { "error": { "code": 0, "message": "" }, "urls": [ { "hash": "mytiny", "long_url": "http://example.com", "short_url": "johndoe.com/mytiny", "short_url_with_protocol": "http://johndoe.com/mytiny", "total_clicks": 0, "unique_clicks": 0, "note": "lots of notes...", "email_stats": false, "expiration_date": "2016-01-02", "max_clicks": 0, "tags":["group1"], "links":{ "qr_small": ..., "qr_big": ... }, "error": { "code": 0, "message": "", "details": "" } } ] } Example of shortening errors: { "error": { "code": 0, "message": "" }, "urls": [ { "long_url": "http://google.com", "custom_hash": "h", "error": { "code": 1215, "message": "Short URL is not correct or existed.", "details": "That Custom hash is already in use" } } ] } In both cases (successful shortening or shortening errors) HTTP status code - 200 OK and top-level "error" block indicates no errors. But inside "urls" array, some URLs may have individual error message. In above example, one URL was successfully shortened. And other URL was not shortened. Normally our system allows creation of multiple different short links containing exactly the same long or destination URL. But it is also possible to avoid making any new, unique short hashes if the long url had been previously submitted. When your API call doesn't specify a custom_hash it is possible to avoid duplication of long URLs by passing the optional parameter "disable_long_url_duplicates": POST /urls?disable_long_url_duplicates=account In this case, new records won't be created for existing long URLs. Records from previously created links will be returned instead. If you specify custom_hash together with "disable_long_url_duplicates" parameter, three scenarios are possible: If custom_hash does not exist, new record will be created If custom_hash exists with same long URL, existing records will be returned If custom_hash exists with different long URL, error 1215 will be indicated Reading URLs GET /urls - get a batch (50) of most recent URLs. { "error": { "code": 0, "message": "" }, "urls": [ { "hash": "h", "long_url": "http://google.com", "short_url": "m.tiny.cc/h", "total_clicks": 0, "unique_clicks": 0, "last_visit": null, "email_stats": false, "protected": false, "ping": false, "archived": false, "note": "", "expiration_date": null, "max_clicks": 0, "tags":[], "links":{ "qr_small": ..., "qr_big": ... } }, { "hash": "g", "long_url": "http://yahoo.com", "short_url": "m.tiny.cc/g", "total_clicks": 0, "unique_clicks": 0, "last_visit": null, "email_stats": false, "protected": false, "ping": false, "archived": false, "note": "", "expiration_date": null, "max_clicks": 0, "tags":[], "links":{ "qr_small": ..., "qr_big": ... } }, . . . ], "page": { "results_count": 13, "total_count": 13, "offset": 0 } } HTTP status code - 200 OK It is also possible to paginate URLs like this GET /urls?offset=10&limit=20 Other supported parameters: "search" - search string (match "long_url", "note" or "hash" fields). In case you are using "search" parameter, property page.total_count in response will indicate total number of matching URLs. "order_by" - possible values: "created" - Creation date, "clicks" - Total clicks, "hash" - Tiny alphabetical, "modified" - Modification date, "favorite" - Favorite first Example: GET /urls?offset=5&limit=1&search=john&order_by=clicks Read single URL: GET /urls/[hash] To read a group of URLs you need to pass a group of hashes in query parameter "hashes", separated with comma. For example, lets pass a group of three hashes (a,b,c): GET /urls?hashes=a%2Cb%2Cc Each individual URL entry has "links" section listing locations of related resources. Editing URLs There are three styles to edit URLs. First style - edit single URL. PATCH /urls/[current_hash] Input params: { "urls": [ { "custom_hash": "new_hash", "long_url": "http://example.com", "note": "new note", "email_stats": false, "expiration_date": "2016-01-02", "tags":["+new_tag","-old_tag"] } ] } All fields are optional. Tags field contains instructions for adding and removing tags. Tags prefixed with "+" will be attached to URL. Tags prefixed with "-" will be detached from URL. Second style - set same properties for many URLs. URL hashes should be listed in "hashes" parameter and separated by comma. PATCH /urls?hashes=a%2Cb%2Cc Input params: { "urls": [ { "note": "collective note" } ] } The above call will set "note" property for URLs with hashes "a","b" and "c". Third style - arbitrary edit many URLs PATCH /urls Input params: { "urls": [ { "hash": "a", "note": "polite note" }, { "hash": "b", "note": "creative note" }, { "hash": "c", "note": "boring note" } ] } In this case "hash" field is mandatory. Response of all three styles have the same structure. And it is similar to the structure of POST call ("page" section is not included). It is also possible to edit many URLs using tags . But is this case only "note", "expiration_date", "max_clicks", "email_stats", "ping", "protected", "archived" fields may be edited. When editing with tags, no URLs returned with response. Deleting URLs DELETE /urls/[hash] Input params: hash - tiny hash associated with URL. It is also possible to pass a group of hashes in query parameter "hashes", separated with comma. For example, lets pass a group of three hashes (a,b,c): DELETE /urls?hashes=a%2Cb%2Cc Example response: { "error": { "code": 0, "message": "" } } HTTP status code - 200 OK NOTE: URLs with "protected" flag never deleted! Stats Reading click stats for individual URL: GET /stats/[hash] { "error": { "code": 0, "message": "" }, "stats": [ { "hash": "e", "total_clicks": 22, "unique_clicks": 1 } ] } Resetting stats for individual URL: DELETE /stats/[hash] Input params: hash - tiny hash associated with URL. It is also possible to pass a group of hashes in query parameter "hashes", separated with comma. For example, lets pass a group of three hashes (a,b,c): DELETE /stats?hashes=a%2Cb%2Cc Example response: { "error": { "code": 0, "message": "" } } HTTP status code - 200 OK Group Operations Group operations with URLs are limited to a maximum number of items. Currently: 50. If you exceed this limit, you will experience an error 1221. This limitation doesn't apply to operations with usage of tags (PATCH, DELETE). It, for example, means, that you are allowed to delete a limited number of URLs listing their hashes in "hashes" parameter. But you can delete URLs, that conform with tags query all in single call. Client libraries README file contains a "Mass shortening" reference which means group or "batch." There is no practical difference between "batch" and "not batch" operations. All operations are "batch". Batch can contain a single entity or multiple entities. For convenience, two different methods are shown in clients: • shorten() to work with a single URL. • mass_shorten() to work with arrays of URLs. Both methods use the same API endpoint. And produce similar results. Error Codes 0 -- '' (empty message string means OK) 101 -- 'Unknown error' 1204 -- 'Not a valid Short URL hash' 1206 -- 'URL you tried to shorten was invalid' 1215 -- 'Short URL is not correct or existed' 1216 -- 'URL you tried to shorten is not allowed' 1217 -- 'Access Denied' 1218 -- 'Short URL is not correct' 1219 -- 'Target server on cooldown' 1220 -- 'URLs limit has been reached' 1221 -- 'Exceeded limit of batch operation' 1300 -- 'Invalid API key'

  • This webpage has 1950 words which is between the recommended minimum of 250 words and the recommended maximum of 2500 words - GOOD WORK.

Header tags:

  • It appears that you are using header tags - this is a GOOD thing!

Spelling errors:

  • This webpage has 2 words which may be misspelt.

Possibly mis-spelt word: url

Suggestion: URL
Suggestion: curl
Suggestion: purl
Suggestion: hurl
Suggestion: burl
Suggestion: furl
Suggestion: Burl
Suggestion: urn

Possibly mis-spelt word: TINYCC

Suggestion: TINY CC
Suggestion: TINY-CC
Suggestion: TINY

Broken links:

  • This webpage has no broken links that we can detect - GOOD WORK.

Broken image links:

  • This webpage has no broken image links that we can detect - GOOD WORK.

CSS over tables for layout?:

  • It appears that this page uses DIVs for layout this is a GOOD thing!

Last modified date:

  • We were unable to detect what date this page was last modified

Images that are being re-sized:

  • This webpage has no images that are being re-sized by the browser - GOOD WORK.

Images that are being re-sized:

  • This webpage has 2 images that do not have their width and height specified.

Mobile friendly:

  • After testing this webpage it appears to be mobile friendly - this is a GOOD thing!

Links with no anchor text:

  • This webpage has no links that are missing anchor text - GOOD WORK.

W3C Validation:

Print friendly?:

  • It appears that the webpage does NOT use CSS stylesheets to provide print functionality - this is a BAD thing.

GZIP Compression enabled?:

  • It appears that the serrver does NOT have GZIP Compression enabled - this is a NOT a good thing!