Namespaces

Welcome to time web services API. This API will cover the common classes and web service methods used to interact with the time tracking system. The time web services support both JSON, XML and SOAP and with JSON being the recommended format to use.

Getting Started

This documentation assumes that you are already familiar with how to connect to the API and are already configured to begin making connections. If you have not made your first initial connection and need an overview for how to get started see the Time System Integration Overview document for how to configure statustime so you can make your first initial connections. Also note that there is a simple SDK that has plenty of code samples to get you going. To stay updated on the API changes see the Change-log.

Stratustime does not accept URL Encoded values. When sending JSON or XML requests, the message must be included in the payload of the request.

The Time API requires TLS 1.2.

Connection Points

The time system is a brand-aware application which means the URL that you point your requests at are very important. The time system manages its brands via a sub-domain name. A brand is basically a grouping of customers. For example all brands and customers reside on the following URL https://centralservers.com however only some customers are accessible via https://mybrand.centeralservers.com vs https://defaultbrand.centeralservers.com or other possible sub-domain setups. Please make sure you are accessing the correct URL for access to your customers data.

FAQs

When sending time in JSON format, it must be sent as epoch milliseconds.
The following common endpoints are in Version 1.0:
TimeGetPunchesByEmpIdentifier
TimeAddPunchByEmpIdentifier
TimeExport

Caution
Endpoint Connectivity: Pointing your web service request at the wrong URL will render your access invalid. Please make sure you know your full URL ahead of time before trying to connect. If you are not 100% sure what your URL will need to be before trying to connect please contact your support administrator for help with identifying your correct endpoint. Endpoint Stability Recommendations: The time system is currently housed and powered by Microsoft Azure data centers. With redundancy built into the Azure infrastructure it is still possible for web services to temporarily go off-line or return a temporary unable to reach message when trying to reach a specific web node in the Azure stack. While this is not common it can and does happen. This is why it’s very important for endpoints calling into the time API to build in extra redundancy into each call. If an endpoint calls a specific web service and it time-outs we recommend a retry loop of 5 iterations. If after the 5th attempt a timeout still resumes, then try additional 5 requests with a 30 second delay between each request. This is especially important for longer running web service requests. For a full overview of this issue please visit the Microsoft Azure Website

Caution

Endpoint Connectivity:
Pointing your web service request at the wrong URL will render your access invalid. Please make sure you know your full URL ahead of time before trying to connect. If you are not 100% sure what your URL will need to be before trying to connect please contact your support administrator for help with identifying your correct endpoint.

Endpoint Stability Recommendations:
The time system is currently housed and powered by Microsoft Azure data centers. With redundancy built into the Azure infrastructure it is still possible for web services to temporarily go off-line or return a temporary unable to reach message when trying to reach a specific web node in the Azure stack.

While this is not common it can and does happen. This is why it’s very important for endpoints calling into the time API to build in extra redundancy into each call. If an endpoint calls a specific web service and it time-outs we recommend a retry loop of 5 iterations. If after the 5th attempt a timeout still resumes, then try additional 5 requests with a 30 second delay between each request. This is especially important for longer running web service requests. For a full overview of this issue please visit the Microsoft Azure Website

Caution
Docs Notice: The tree-view on the left has been modified to help make reading easier. The "AppOne.Web.Service."namespace portion has been removed from the table of contents for version 1.0 and "AppOne." from version 2.0. Usability Tags: SCHEMA Schema represents a possible blue print for a proposed model that may be exposed in the future. These contracts and endpoints have no functionality and return no results. BETA Some versions of the API are pre-leased for beta testing. If you see this tag do NOT implement business logic on the method or its contract in a production environment as it is subject to change. The methods are being released for testing purposes only. See V1 ServiceRouter for quick overview. See V2 ServiceRouter for quick overview. UPGRADE Upgrade tags indicate that the operation has become obsolete in favor of a newer version and users are encouraged to update to the newer version when feasible. If an operation has an upgrade tag then it will no longer be available for feature requests or modifications. SUNSET These tags indicate that the operation will be sunset for various reasons and will have a documented upgrade path given. All sunset tags will have a documented date by which they will be provisioned to be removed. Please review the methods docs and the changelog for date details on each method.

Caution

Docs Notice:
The tree-view on the left has been modified to help make reading easier. The "AppOne.Web.Service."namespace portion has been removed from the table of contents for version 1.0 and "AppOne." from version 2.0.

Usability Tags:

**SCHEMA**
Schema represents a possible blue print for a proposed model that may be exposed in the future. These contracts and endpoints have no functionality and return no results.

**BETA**
Some versions of the API are pre-leased for beta testing. If you see this tag do NOT implement business logic on the method or its contract in a production environment as it is subject to change. The methods are being released for testing purposes only.

See V1 ServiceRouter for quick overview.
See V2 ServiceRouter for quick overview.

**UPGRADE**
Upgrade tags indicate that the operation has become obsolete in favor of a newer version and users are encouraged to update to the newer version when feasible. If an operation has an upgrade tag then it will no longer be available for feature requests or modifications.

**SUNSET**
These tags indicate that the operation will be sunset for various reasons and will have a documented upgrade path given. All sunset tags will have a documented date by which they will be provisioned to be removed. Please review the methods docs and the changelog for date details on each method.

Note
Version 2.0 enhancements include: - Inbound query capabilities with [DataAction] structure for Get operations - Inbound filtering capabilities with [DataFilter ]structure for post processing of Get operations - [Report ] structure details for Get response operations - More flexibility for inbound and outbound parameter handling - Improved performance and stability with the back end - Batch processing for larger result sets

Note

Version 2.0 enhancements include:
- Inbound query capabilities with [DataAction] structure for Get operations
- Inbound filtering capabilities with [DataFilter ]structure for post processing of Get operations
- [Report ] structure details for Get response operations
- More flexibility for inbound and outbound parameter handling
- Improved performance and stability with the back end
- Batch processing for larger result sets

Namespaces

Namespace	Description
AppOne.Services.V2	The namespace AppOne.Services.V2 is used to store all entities and classes that are shared across all versions of the version 2.0 interface. This top level namespace contains the base classes and common service exception classes that are used throughout both the Contracts and Methods namespaces.
AppOne.Services.V2.Contracts	Contracts are broken out into a separate namespace as they tend to denote the pure class or entity of the underlying object that is reflected in the data store. These classes represent the data entities themselves that are passed between services.
AppOne.Services.V2.Methods	The Methods namespace represents every available method/operation that can be accessed in the version 2.0 schema
AppOne.Web.Service.Services	The time web services topmost namespace AppOne.Web.Service.Services is used to store all entities and classes that are shared across the V1 namespace.
AppOne.Web.Service.Services.V1R0	The namespace AppOne.Web.Service.Services.V1R0 is shorthand for version 1 revision 0. AppOne.Web.Service.Services.V1R0 is used to store all entities and classes that are shared across all versions of V1R0.
AppOne.Web.Service.Services.V1R0.Customer	This namespace is for all customers on a particular version and revision such as AppOne.Web.Service.Services.V1R0.Customer. All customers are associated with a brand where a brand can have many customers and is denoted by a unique URL such as: http://mybrand.centralservers.com. Where "mybrand" is considered the brand. This namespace differs from the AppOne.Web.Service.Services.V1R0.Customer.Contracts in that it tends to show most of the actionable services calls. The Contracts namespace on the other hand deals more with the entities and data points that are used to populate a given data-store such as a database.
AppOne.Web.Service.Services.V1R0.Customer.Contracts	Customer contracts are broken out into a separate namespace as they tend to denote the pure class or entity of the underlying object that is reflected in the data store. These classes represent the data entities themselves that are passed between services.