API Services For Wayne RESA Developed Enterprise Resource Planning (ERP) System

RFP # WRESA-50-2026-2027-07
REQUEST FOR PROPOSALS
FOR
API SERVICES FOR WAYNE RESA
DEVELOPED ENTERPRISE RESOURCE
PLANNING (ERP) SYSTEM

BID SUMMARY
Commodity/Service Being Requested: API Services for Wayne RESA Developed Enterprise Resource Planning (ERP)
System
Type of Solicitation: Request for Proposals (RFP) - Wayne RESA, in partnership with the CoPro+ cooperative
purchasing program managed by the Public Procurement Institute of Michigan (PPIM), a nonprofit organization, is
competitively bidding and awarding a Master Agreement to a Contractor or Contractors for API Services for Wayne
RESA Developed Enterprise Resource Planning (ERP) System.
Type of Resulting Contract: Statewide Cooperative Contract - As a result of this RFP, Wayne RESA will work with the
CoPro+ cooperative purchasing program to market and extend the resulting Contract to other public municipalities, non-
profit organizations and schools statewide in having access to Contract(s) for API Services for Wayne RESA Developed
Enterprise Resource Planning (ERP) System. This Contract will enable public municipalities, non-profit organizations,
and schools to "piggyback" and purchase commodity/service on an "as needed" basis from the Proposer(s). Proposers
shall list which regions you will service and identify any limitations on commodities and/or services areas within
Appendix A - Regional Map, within this RFP.
Resulting Contract Term: Three (3) year with two (2) one-year renewal options. The base term for this Contract is for
three (3) years. At the end of the initial term, this Agreement will be evaluated. If the parties agree that it is a mutually
beneficial relationship, the Agreement may be extended through a signed Amendment by both parties for up to two (2)
additional one (1) year options, which may be exercised individually or together.
RFP TIMETABLE DATE / TIME
RFP Issue Date August 14, 2026
Pre-Proposal Meeting**: September 2, 2026, at 10:00 a.m. Eastern Time
September 4, 2026, by 12:00 p.m. Eastern
Submission of Question(s) from Proposer Due Time
Answers to Proposer Questions Due September 11, 2026
September 16, 2026, by 12:00 p.m. Eastern
Proposals Due* Time
Contract Start October 2026
*Responses received later than the specified deadline will be disqualified.
** Pre-Proposal Meeting is strongly encouraged, though it is not mandatory to attend. The Pre-Proposal Meeting will be
held virtually via Microsoft Teams on September 2, 2026, at 10:00 a.m. Eastern Time. Please see the meeting link, ID,
and passcode below.
Topic: API Services for Wayne RESA Developed Enterprise Resource Planning (ERP) System
Day/Time: September 2, 2026, 10:00 a.m. Eastern Time (US and Canada)
Join Teams Meeting:
https://teams.microsoft.com/meet/296810290566727?p=fBWZ1hqg87BmLdTAal
Meeting ID: 296 810 290 566 727
Passcode: 4Sz3Dc3o
2
RFP # WRESA-50-2026-2027-07

Selected Proposers may be required to participate in interviews and/or make oral presentations. Failure of a Proposer to
participate on the date scheduled may result in the rejection of the Proposer's proposal. In addition, Wayne RESA may
decide to make site visits to the selected Proposers' reference sites or other sites provided by the Proposer.
Wayne RESA reserves the right to change this schedule as needed and all information provided by Wayne RESA in this
RFP is offered in good faith. Individual items are subject to change at any time. Wayne RESA makes no certification that
any item is without error.
The Sole Point of Contact During this Solicitation Process is:
Stacey Shaw
purchasing@resa.net
(989) 307-1307
Contacts with Wayne RESA Personnel: All contact with Wayne RESA regarding this RFP or any matter relating
thereto must be sent to the following email: purchasing@resa.net
Electronic forms of all bid documents are available online at: Wayne RESA Bid Documents
If you experience any issues downloading the documents, contact Stacey Shaw at purchasing@resa.net
Award of this proposal is contingent upon the approval of funding from Wayne RESA Board of Education.
3
RFP # WRESA-50-2026-2027-07

Table of Contents
SECTION 1.0 - PROPOSER RESPONSES TO SCOPE OF WORK AND PRICING 5
1.1 Minimum Mandatory Requirements 5
1.2 Introduction and Background 6
1.3 Scope of Work 6
1.4 Statewide Cooperative Contract 14
1.5 Reserved 15
1.6 Service Capabilities 15
1.7 Customer Service 16
1.8 Purchase Orders 16
1.9 Delivery and Acceptance 16
1.10 Criminal Background Check 17
1.11 Pricing Schedule 18
1.12 Price Assurance 18
SECTION 2.0 - PROPOSER INFORMATION AND ACCEPTANCE 20
2.1 Company Profile 21
2.2 References 22
2.3 Assurances and Certifications 23
SECTION 3.0 - BIDDING, EVALUATION, SELECTION & AWARD PROCESS 28
3.1 Wayne RESA Responsibility 28
3.2 Truth and Accuracy of Representations 28
3.3 Proposers Questions 28
3.4 Preparation of the Proposal 28
3.5 Bid Submission Deadline 29
3.6 Adherence to Minimum Mandatory Requirements (Pass/Fail) 29
3.7 Evaluations Process 29
3.8 Evaluation Criteria 30
3.9 Optional Tools to Enhance Evaluation Process 30
3.10 Wayne RESA Option to Reject Proposals 30
3.11 Freedom of Information Act 30
3.12 Contacts with Wayne RESA Personnel 31
3.13 Final Agreement Award Determination 31
3.14 Cancellation of Invitations for Bids or Requests for Proposals 31
APPENDIX A - Regional Map 32
ATTACHMENT A - PRICING SCHEDULE
Solicitation Terms and Conditions can be found at https://www.resa.net/administrative-support/purchasing/request-for-
proposal as (DOC) CoPro+ Contract Terms and Conditions
4
RFP # WRESA-50-2026-2027-07

SECTION 1.0 - PROPOSER RESPONSES TO SCOPE OF WORK AND
PRICING
PROPOSAL RESPONSE GUIDELINES
The following are guidelines for the content of your proposal submission. Please review the guidelines below in full prior
to beginning your proposal.
Proposal Section I - Executive Summary
This part of the response to the RFP should be limited to a brief narrative highlighting the supplier's proposal. The
summary should contain as little technical jargon as possible and should be oriented toward non-technical personnel. The
summary should describe the following:
* Your understanding of the scope of requirements and the level to which your proposal has met the
requirements.
* Key differentiators in service offerings, account management, and value-added services proposed by your
company and outcomes delivered to WRESA.
* High-level project execution plan and timeline for completion, outlining any delays that could impact
availability.
* Risk management considerations.
Proposal Section II - Scope of Proposed Solution
Provide a description of the overall solution or methodology for API Services for Wayne RESA Developed Enterprise
Resource Planning (ERP) System. Confirm that the solution being provided is comprehensive and meets the
requirements. In addition, describe the methodology for solution delivery. Finally, describe the client relationship
management approach (e.g., steering committee, status reporting).
Proposal Section III - Comprehensive List of Assumptions
Rather than have assumptions scattered throughout the proposal, WRESA requires that all assumptions be listed and
explained in this section. Please ensure that all assumptions listed reference the appropriate section of the RFP and/or
associated services.
1.1 Minimum Mandatory Requirements
All proposals will be reviewed for compliance with the minimum mandatory requirements. Proposals deemed non-
responsive will be eliminated from further consideration.
Interested and qualified proposers that can demonstrate their ability to successfully provide the services requested under
this RFP are invited to submit proposal(s), provided they meet the following:
1. The proposer must have a minimum of five (5) years of experience providing API Services.
2. The proposer must provide a minimum of three (3) references from current or former clients for whom the Proposer
has successfully performed services comparable in size, scope, and complexity to those required under this RFP.
5
RFP # WRESA-50-2026-2027-07

Enter 3 references in Section 2.2 References.
3. The proposer must complete and submit Attachment A - Pricing Schedule with their proposal.
1.2 Introduction and Background
Wayne RESA, established by the Michigan Legislature in 1960, is the largest of fifty-six (56) such agencies throughout the
state. The Wayne RESA board is elected by one vote from each of the thirty-three (33) local Wayne County school district
boards. WRESA provides a wide variety of services to thirty-three (33) public school districts and approximately ninety-
seven (97) public school academies in Wayne County, Michigan; serving more than 260,000 students. WRESA, through
various consortium arrangements, provides a variety of services to other educational agencies throughout the state of
Michigan.
Wayne RESA is issuing this Request for Proposals (RFP) to solicit competitive bids from qualified contractors to design,
develop, and implement a secure, scalable, and modern Application Programming Interface (API) layer for our in-house
Enterprise Resource Planning (ERP) system, known as SMART.
The SMART system serves as a mission-critical operational hub. However, its current lack of a standardized external
integration layer limits its ability to communicate efficiently with modern third-party applications, cloud services, and
partner systems. The goal of this project is to build a robust API layer that eliminates technical silos, reduces administrative
overhead, and establishes a secure pathway for real-time data exchange.
The primary business objectives for the SMART API project include:
* Eliminating Manual Data Entry: Replacing legacy, error-prone manual data entry and flat-file manipulation with
direct, automated system-to-system communications.
* Improving Data Consistency: Establishing a single version of truth across connected platforms by enabling near-
real-time synchronization with SMART.
* Enhancing Process Efficiency: Streamlining workflows across departments by enabling external vendor
applications to query and post data directly to authorized SMART modules.
* Targeted Ecosystem Connectivity: Providing a seamless bridge between SMART and critical business vectors,
specifically external human resources (HR) platforms, cloud infrastructure hosting environments, and distributed
cloud document storage platforms.
* Scalable Cooperative Extensibility: Aligning the technical architecture with a framework that allows participating
public municipalities, non-profit organizations, and statewide educational institutions to securely interface with
shared services through standardized access patterns.
1.3 Scope of Work
The Proposer may utilize the "Proposer Response" boxes AND/OR may respond/acknowledge to the Specifications and
Requirements within their proposal. However, each section, subsections, etc., MUST be clearly referenced within the
proposal.
1.3.1 Specifications and Requirements
6
RFP # WRESA-50-2026-2027-07

A. Existing Technical Environment
1. The SMART ERP system is a proprietary, in-house built platform. Proposers must demonstrate deep
technical competency in the following underlying environments to ensure a native, highly performant API
architecture:
a. Database Layer: Microsoft SQL Server. The database relies on complex relational schemas, stored
procedures, views, and transactional indexing optimized for ERP operations.
b. Application Framework: Microsoft .NET framework leveraging the Model-View-Controller (MVC)
architectural pattern.
c. Business Logic: Much of the core operational validation and business rules are embedded directly
within the .NET MVC controller/service layers and SQL Server stored procedures.
d. Database Size: 3.6 TB.
e. Hosting Environment: On Prem, Client/Server, and Web Hosting.
f. Estimated Number of Current Users: 35,000
B. Current Integration Environment
1. Presently, data exchange between SMART and external systems is heavily reliant on legacy processes,
including:
a. Scheduled overnight batch processing via Secure File Transfer Protocol (SFTP) using GoAnywhere
software.
b. Manual CSV/Excel data extractions and uploads.
c. Direct database-level read access for specific reporting tools (which bypasses application-layer
business rules).
2. The selected contractor will be tasked with abstracting this legacy infrastructure behind a clean, unified
API layer that respects existing .NET business logic models and prevents direct database exposure to
external actors.
Proposer Response:
I have reviewed the above requirements and agree with no exceptions.
I have reviewed the above requirements and have noted all exception(s) below.

List all exception(s):
Bidder must describe how they comply with the above requirement(s):
C. Required Business Integrations
7
RFP # WRESA-50-2026-2027-07

1. The API layer must securely expose endpoints to support data movement, transactional actions, and
synchronization across our three target architectural integration pillars:
a. Human Resources and Financial Platforms: Automating employee lifecycle syncing, directory
provisioning, security role assignments, organizational charts, payroll/benefit system integrations, and
order processing from systems like Amazon Business.
b. Amazon Web Services (AWS) Ecosystem: Communicating natively with AWS services for off-site
data processing pipelines, centralized cloud infrastructure monitoring, backups, and enterprise analytics
architectures.
c. Document Storage Platforms: Supporting automated document routing, metadata synchronization,
employee file indexing, and external contract or record management platforms.
Proposer Response:
I have reviewed the above requirements and agree with no exceptions.
I have reviewed the above requirements and have noted all exception(s) below.

List all exception(s):
Bidder must describe how they comply with the above requirement(s):
D. Technical and Functional Requirements
1. To encourage the most modern, optimized, and robust infrastructure designs, Wayne RESA is leaving the
exact API standard open to be proposed by vendors. Vendors may propose the architectural standard (e.g.,
RESTful, GraphQL, gRPC, or a hybrid model) that they justify as best matching the SMART technology
stack and integration targets.
a. Payload Format: Proposals should specify preferred data formats (e.g., JSON, XML) and justify how
they optimize integration with HR, AWS, and document storage endpoints.
b. State Management: The API architecture must remain stateless to support scalability across disparate
platforms.
c. Error Handling: Regardless of the chosen architecture (REST, GraphQL, etc.), the system must return
a clean, highly structured, and uniform error logging schema that provides clear context to external
client developers tracking down validation or system failures.
2. The contractor will design and deploy a comprehensive catalog of data access vectors mapping to the
SMART .NET MVC database schema. Endpoints and schemas must include server-side safeguards like
pagination, field-filtering, and index-sorting to prevent open integrations from overwhelming core database
pools.
8
RFP # WRESA-50-2026-2027-07

3. To prevent target systems from constantly polling the SMART database for changes, the API must include
an asynchronous, event-driven webhook framework.
a. Trigger Events: The system must detect data alterations within core SMART tables (such as employee
updates, organizational structural modifications, or document reference alterations) and instantly queue
an outbound alert.
b. Payload Delivery: Outbound webhooks must securely transmit event-specific JSON/XML metadata
to registered external listener URLs within a tight window of the database trigger event.
c. Retry Policy: The webhook engine must utilize an automated exponential backoff retry scheme for
failed transmission attempts (e.g., handling target platform timeouts or unexpected 5xx responses).
Proposer Response:
I have reviewed the above requirements and agree with no exceptions.
I have reviewed the above requirements and have noted all exception(s) below.

List all exception(s):
Bidder must describe how they comply with the above requirement(s):
E. Security, Governance, and Performance Requirements
1. Security is paramount. Open architecture does not mean open access; unauthenticated endpoints or direct
database access exposure will result in immediate proposal disqualification.
a. Protocol: The API layer must utilize industry-standard identity protocols (e.g., OAuth 2.0 Client
Credentials or Authorization Code flows) backed by cryptographically secure tokens (such as JWTs).
b. Access Control: Implement granular, Role-Based Access Control (RBAC) and scope-based
permissions. The system must explicitly confirm that the connecting entity possesses the precise scope
needed for the requested block of data.
c. Secret Management: API keys, certificates, integration secrets, and database connection
configurations must be handled using secure environment variable configurations or dedicated vaults,
never hardcoded within the codebase.
d. Encryption in Transit: All inbound and outbound integration traffic must be strictly enforced over
HTTPS utilizing industry-standard cryptographic protocols (TLS 1.2 minimum, TLS 1.3 preferred).
Non-secured HTTP traffic must be rejected.
e. Encryption at Rest: Sensitive payload logs, access configurations, and personally identifiable
information (PII) must be encrypted at rest using strong cryptographic standards (e.g., AES-256).
f. Regulatory Compliance: The solution must firmly adhere to all student and organizational data
privacy mandates (such as FERPA) and demonstrate alignment with enterprise-grade security
structures like SOC 2 Type II or ISO 27001.
9
RFP # WRESA-50-2026-2027-07

g. Rate Limiting & Throttling: To protect the .NET MVC architecture from crashing under spike loads
from external HR syncs or bulk AWS batch tasks, the API layer must implement rate limiting. Exceeded
caps must gracefully reject requests with an appropriate high-traffic status indicator (e.g., HTTP 429).
h. Audit Trails & Logging: The platform must write exhaustive interaction logs tracking caller metadata,
accessed methods, source IP locations, and payload status. To safeguard institutional data security, logs
must thoroughly redact sensitive values, personal passwords, or financial strings.
2. The final API solution must meet or exceed the following technical operation baselines:
a. Uptime Availability: Minimum 99.99% operational uptime availability outside of pre-scheduled,
authorized system maintenance windows.
b. Response Latency: Standard, non-bulk read operations must complete their data execution cycle
within highly responsive latency baselines under standard operating loads.
Proposer Response:
I have reviewed the above requirements and agree with no exceptions.
I have reviewed the above requirements and have noted all exception(s) below.

List all exception(s):
Bidder must describe how they comply with the above requirement(s):
F. Implementation & Project Management
1. To satisfy operational mandates, the entire API system must be fully developed, security audited, and
functional in production by the end of 2026. Proposers must align their engineering workflows to fit within
this rigid timeframe, starting immediately upon the anticipated contract award in September 2026:
a. Phase 1: Discovery & Architecture Mapping (September 2026): Contractor kick-off, validation of
the bidder's proposed API standard against the .NET MVC framework, endpoint definition mapping,
and final technical architecture approval.
b. Phase 2: Core Engineering & Sandbox Provisioning (October - November 2026): Provisioning
isolated developer environments, drafting core service logic against SQL Server schemas, and
implementing the chosen token-based authentication engine.
c. Phase 3: Security Layer & Target Integrations (December 2026): Setting up webhook services,
applying rate-limiting, activating robust logging middleware, and wiring up endpoints to initial external
test setups (HR, AWS, Document Storage).
d. Phase 4: QA, Security Audit & Production Launch (January 2027): Executing load testing,
conducting data integrity verification, finishing penetration/vulnerability scans, and moving to an active
production deployment before year-end.
10
RFP # WRESA-50-2026-2027-07